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.

[bond]

cool stuff! thanks a lot :)

[virus]

So, after almost sinking into several assorted troubles, I've finally completed the PSNR test I started a while ago (look at the corresponding post on page 2 for further details about settings, source, bitrate, ...). I've added some x264 results as well as VP6.2 (sharpness 7, Best quality, "Best PSNR" postprocessing = deblocking only).

VP6.2: 43.76 dB
x264 (more iterations): 43.39 dB
x264 (Qpel on all): 43.35 dB
XviD (HPel): 43.03 dB
XviD (QPel): 42.91 dB
x264 (Hpel): 42.79 dB

finally we can see x264 among the masters :)

[netchris]

Well done virus!

finally we can see x264 among the masters

if you think how immature x264 is and still can achieve such results :D

I am curious if we will see an even higher psnr if you decrease the deblock beta to something like -5 or -4.
The image will be sharper (and vp6 has very high sharpness with the chosen options).

[Manao]

Default deblocking settings were computed to give the best psnr, so I doubt playing with these settings will increase psnr.XviD (HPel): 43.03 dB
XviD (QPel): 42.91 dBI'm curious, what was the clip you used ?

[akupenguin]

I don't know what he used, but I've seen XviD's qpel give up to 0.5 dB worse than hpel, on anime.

And yes, deblock vars = 0 is the optimal setting for PSNR. (maybe +/- 1 for some sources, but you're not going to gain much.) The options are just in case you prefer sharpness or smoothness over mathematical accuracy. (I personally think 0 looks best, too.)

[virus]

Originally posted by Manao
I'm curious, what was the clip you used ?
It's Ghost Ship DVD (PAL), chapter 3, 1000 frames.
Reasonably clean source. This is a very high motion clip featuring small, detailed sea waves, large near-uniform areas (sky+clouds), a wide range of difficult edges, some closeups on faces, a few underwater detailed frames and even some hardcoded text - all in 40 seconds. My reference clip for high-motion DVD content. The caps on page 2 of this thread can give you an idea.

As for the results with QPel/HPel, I don't know. Maybe with long MVs you have a better chance to have hpel vectors do the job well, without that extra 2 bits/MB. Instead, if you have a low-motion clip with many "static" MBs they may need some small MV like (0.25, 0.25) due to slight camera movements, and thus you may end up with more MBs (on average) which "need" QPel and overall, you can compensate better the MV overhead. But this is really just speculation... I failed to come up with a better explanation :)

IIRC gruel once said that re-encoding MPEG-2 material - which uses HPel only - can reduce QPel effeciency due to the way MPEG-2 handles subpel interpolation. So maybe on DVDs you simply have a better chance to find a clip where HPel works better than QPel.

[akupenguin]

Originally posted by virus
IIRC gruel once said that re-encoding MPEG-2 material - which uses HPel only - can reduce QPel effeciency due to the way MPEG-2 handles subpel interpolation. So maybe on DVDs you simply have a better chance to find a clip where HPel works better than QPel.
That too. When re-encoding from a lossy format, you gain PSNR (though not necessarily visual quality) by using a format/setting that reproduces the same artifacts as in the original. One such artifact is quantization of motion vectors.
This effect can be reduced by pp/crop/scale/denoising the video (which you should do anyway, unless you really need to know how well the codecs can accurately reproduce noise).

[pogo stick]

It's so good to see that x264 is growing up!
I tried it in ffdshow and it looks nice. :)
Akupenguin, what do you think about interlaced encoding support?
Can we expect it any time soon? Or this feature have low development priority?
Originally posted by celtic_druid
Also the last mplayer/mencoder build that I did has x264 enabled. Build is optimised for athlon-xp's though.
Should this build work for P4 under WinXP?
I am getting this error when I use '-ovc x264':

http://pogo-stick.nm.ru/menc.jpg

And other errors when I use another codecs.
It's the first time I am trying mencoder, so I may miss something important about it.
What can be wrong?

[IgorC]

where can i get this codec?

[Sirber]

It's part of FFDShow (VFW) and mplayer (win32/linux).

[celtic_druid]

Correct me if I'm wrong but P4's don't have 3DNow, so I wouldn't expect a Athlon-XP build to run on a P4 any more than a P4 build to run on a XP. Guess both would run fine on AMD64's though.

[akupenguin]

Originally posted by pogo stick
Akupenguin, what do you think about interlaced encoding support?
Can we expect it any time soon? Or this feature have low development priority?
Interlacing is ugly. And unlike B-frames, it's not just the implementation that's ugly, but also the results. So, no, I refuse to have anything to do with interlaced video.
If you have telecined content, ivtc it. If you have an interlaced capture device, set it to progressive. If you're capturing interlaced TV or the like, accept the fact that it's half the resolution it purports to be, and the best you can do is interpolate the missing pixels (a.k.a. deinterlace).

[Sirber]

Originally posted by celtic_druid
Correct me if I'm wrong but P4's don't have 3DNow, so I wouldn't expect a Athlon-XP build to run on a P4 any more than a P4 build to run on a XP. Guess both would run fine on AMD64's though. AMD:
3DNOW!, 3DNOW!+

P4:
SSE2, SSE3

If the builds has been harcoded optimized with those feature, it might crash :)

[pogo stick]

Originally posted by celtic_druid
Correct me if I'm wrong but P4's don't have 3DNow, so I wouldn't expect a Athlon-XP build to run on a P4 any more than a P4 build to run on a XP. Guess both would run fine on AMD64's though.
I see now. I am clueless about these things. Can you, please, compile it for P4, if that wouldn't be too bothering?
Or is there a place where I can look for P4 builds with x264 enabled?
Originally posted by akupenguin
Interlacing is ugly. And unlike B-frames, it's not just the implementation that's ugly, but also the results. So, no, I refuse to have anything to do with interlaced video.
But why it's ugly?
mpeg2 people don't deinterlace usually.
And interlaced XviD video look good with bob post-deinterlacing.
Is it much different in H.264?


off topic: Sirber, what happened to your avatar? It was much nicer before.

[Sirber]

Originally posted by pogo stick
off topic: Sirber, what happened to your avatar? It was much nicer before. Someone told me it was looking childish and desperate :eek:

[virus]

@akupenguin

I've tried compiling x264 myself using MinGW and had a little problem. I used Makefile.cygwin but it lacks a file in the SRCS definition. You need to add encoder/eval.c to the file list. Here's the patch if you want to commit it (hope I didn't mess with svn diff, I'm pretty n00b with this stuff :D):

Index: Makefile.cygwin
===================================================================
--- Makefile.cygwin (revision 51)
+++ Makefile.cygwin (working copy)
@@ -9,7 +9,7 @@
core/common.c core/mdate.c core/csp.c \
encoder/analyse.c encoder/me.c encoder/ratecontrol.c \
encoder/set.c encoder/macroblock.c encoder/cabac.c encoder/cavlc.c \
- encoder/encoder.c \
+ encoder/encoder.c encoder/eval.c \
core/i386/mc-c.c core/i386/dct-c.c core/i386/predict.c \
x264.c

mmmh... the tabs have been converted... better if you rerun manually on your sources ;)

[Bogalvator]

I used the makefile in the build/cygwin directory and it worked fine - is there any difference in the outputs?

[virus]

Ok, I managed to compile the broken VfW interface (with only a few changes to the code).

It's outdated (only 1-pass @ fixed quantizer), and I get a crash after a few seconds of encoding with VDub on my machine. Anyway I've uploaded here (link now removed) the zip with the .dll and the .inf file. To install it, unzip to a temporary directory, right click on the .inf file and choose "Install". Then, you should see x264 in the VDub's codec list. Please test it and see if it crashes and with what options enabled.

I hope to hack it to get it up-to-date and hopefully not crashing, though I'll probably need some help for that.


EDIT: found the problem. I'll have an update (not crashing) soon.

EDIT 2: you can d/l the new file now. Sorry, I didn't realized that SSE2 and MMXEXT were enabled by default. They have been turned off. Right now I cannot decode the clips, though.

EDIT 3: mmmhh, the default FOURCC ("x264") won't work. You need to change it to "H264" and ffdshow will decode just fine. Anyway... my P4 shouldn't have crashed with MMXEXT & SSE2 enabled, no? I believe P4s have MMXEXT, or no?

(promised, I won't edit this post anymore :D)

[netchris]

Many thanks virus!
Its nice to have an alternative (even if it is the same codec exactly :D )
to ffdshows implementation .
Unfortunately the quantizer scale is different in ffdshow compared to x264 vfw.

[akupenguin]

Originally posted by netchris
Unfortunately the quantizer scale is different in ffdshow compared to x264 vfw. Yup. ffdshow had MPEG-style quantizers hardcoded in too many places, so they just rescaled H.264 quant to 1..31 rather than changing the limits. Which is confusing, because H.264 quants are on a logarithmic scale, so rescaling still doesn't make them equivalent to MPEG quants.

[RadicalEd]

Can anyone confirm that the VC6 project files are b0rked or do I just suck at compiling?

[P0l1m0rph1c]

They are b0rked.

[BoNz1]

BTW was the port of the gcc inline assembler to a nasm file completed?

[pogo stick]

I was looking at mplayer's manual and there is bframes option:
bframes=<0-16> number of consecutive B-Frames between I- and P-Frames (default: 0)
I wonder, why it is not in ffdshow?

Originally posted by Sirber
Someone told me it was looking childish and desperate :eek:
No, it's not. It's kinda cheerful. But that b/w thing with little moustache was definitely desperate.
Now I will be able to recognize you even if I will loss my reading ability. :)

[akupenguin]

Originally posted by pogo stick
I was looking at mplayer's manual and there is bframes option. I wonder, why it is not in ffdshow?
Because our implementation of B-frames is incomplete enough that they don't yet improve compression efficiency.

[virus]

I checked a bit better the sources. Well, the VfW frontend is very similar to the XviD one so yes, I think I can do that. (I mean, reworking it completely to support all the new stuff)

@akupenguin: maybe one of you guys is already working on that? If not, maybe I should ask on x264-devel if they need a mantainer for the VfW code?

[akupenguin]

There is officially a maintainer for the VfW code, but I haven't heard from him in months. I'm sure you'd be welcome if you want to take over that role.

[bond]

i couldnt look at the latest vfw version, but plz make as much configuration options as possible available in it, so people can enjoy testing it out and finding good options :)

[virus]

thanks for your support :)

Today I toyed a bit with my resource editor trying to invent a design, or at least something similar :D
Here's a very rough and incomplete draft. No code has been written, this is just my opening bid on the issue. I tried to keep the most important stuff in the first page, and hide the less n00b-friendly whistles behind the "Advanced" button.

Main page:

http://img14.exs.cx/img14/513/x264-gui-1-main.png

The (now) empty Encoding type list will contain stuff like "Single pass - constant bitrate" or "Twopass - 1st pass" and the Quantizer and Bitrate fields will be enabled/disabled accordingly. The Configure button should open a little window for extra configurations, like entering the statsfile name and something similar. Since sliders are bad, buggy and often useless, I'll probably remove the one for max ref. frames, too. The tiny little arrows are much better ;)

As for the Advanced dialog, here's what I came up with:

http://img14.exs.cx/img14/268/x264-gui-1-adv1.png

http://img14.exs.cx/img14/1000/x264-gui-1-adv2.png

http://img64.exs.cx/img64/8935/x264-gui-1-adv3.png

Again: the now empty dropdown lists will be filled in dinamically. Obviously the Tab names are still temporary... though I have no idea what name they should have :)


So, feedback? There was a lot of discussion time ago about reworking the XviD GUI so I hope someone can give useful suggestions... also, did I miss some important options? Did I add useless stuff? Please let me know!

virus

[snacky]

I have some suggestions about interface.

I would try to separate ratecontrol- and quantization parameter-related options into a tab or tabs separate from all the other options. You'd be surprised how many users do not understand which options do what... Anyway, this means a tab with options to limit quantizers, enable 2pass, adjust qblur, etc.

Another tab should focus on options that let you trade off encoding time for higher quality. These are subpel refinement, number of reference frames, CABAC (which should be on by default), and maybe the option as to whether or not to enable the deblocking filter (it should also be on by default). Arguably, deblocking parameter adjustment should probably also be in this tab.

Finally, another tab or section should include frame type decision related parameters. This includes the keyframe interval, frequency of IDR frames, scenecut detection parameter, bframes. I would probably also put the I/P and P/B ratio options in this location, but perhaps it also makes sense to put them in the ratecontrol/quantization tab.

I suggest giving the first tab I described a title that indicates it's all ratecontrol stuff, and the second tab I described should clearly indicate that most or all of its options are quality-vs-speed tradeoffs. That way, users have a better idea of what things they should be trying.

I have a hard time imagining how you can sanely divide up very many options based on how advanced they are, but maybe there turns out to be some benefit to deemphasizing certain options that are unlikely to be changed. For example, qblur, qcomp, and scenecut threshold are probably pretty good the way they are. You can also specify your own ratecontrol equation but people almost never use this. MPlayer's man page has, for several months running now, omitted to even mention that this option exists for x264, and so far nobody has even asked about it :) It also seems pretty darn unlikely that users will want to turn off CABAC or the deblocking filter. The other stuff is arguable maybe, but I can say that personally I don't even bother trying out changes in the interframe block size analysis flags because it never gives me any benefit and the only consistent result is less accurate ratecontrol.

[snacky]

Also, I'm having a hard time thinking of how there can be a legitimate reason for the user to use anything but H264 for the fourcc.

[RadicalEd]

Originally posted by snacky
Also, I'm having a hard time thinking of how there can be a legitimate reason for the user to use anything but H264 for the fourcc.

Perhaps because the official fourcc is "AVC1" :O

[Tommy Carrot]

Originally posted by snacky
It also seems pretty darn unlikely that users will want to turn off CABAC or the deblocking filter.
I definitely would. :D Disabled deblocking filter often gives better results at higher bitrates.
The other stuff is arguable maybe, but I can say that personally I don't even bother trying out changes in the interframe block size analysis flags because it never gives me any benefit and the only consistent result is less accurate ratecontrol.
The analysis flags are supposed to be a tradeoff between speed and quality. Although there is no big speed penalty when all is enabled, i'm not sure if this is the right behaviour, this can be a bug imo.

Personally, i think the less tabs the better, so i agree with snacky's approach: one tab for the rate control and the frame-type decisions, and the other for the speed/quality related options.

[snacky]

Sorry for triple posting, but this is kind of a separate topic: reasonable defaults.

I often use mencoder as a frontend to x264. It's my opinion that its defaults are now almost entirely reasonable. Check here (http://www1.mplayerhq.hu/cgi-bin/cvsweb.cgi/main/libmpcodecs/ve_x264.c?rev=1.7&content-type=text/x-cvsweb-markup) to find them. Even if you don't replicate them exactly, IMO they're a good starting point.

[snacky]

Originally posted by RadicalEd
Perhaps because the official fourcc is "AVC1" :O
Hmm, I didn't know that.

[virus]

Originally posted by snacky
Anyway, this means a tab with options to limit quantizers, enable 2pass, adjust qblur, etc.
I can understand the rest, but maybe 2pass is a bit out of place here?

Another tab should focus on options that let you trade off encoding time for higher quality. These are subpel refinement, number of reference frames, CABAC (which should be on by default), and maybe the option as to whether or not to enable the deblocking filter (it should also be on by default). Arguably, deblocking parameter adjustment should probably also be in this tab.
Here we basically agree. This is the main page (designed to be the only one that a n00b should ever open to do a decent encode ;)) except for the subpel refinement, where I think 4 can be a good enough default value. You lose a lot quality if you go towards 0, so maybe there won't be need to add it to the Main tab imho.

I also thought about adding the deblock params in the main page, but they seem to me a bit too much "technical" for the Main tab. Remember, we are targetting Win32 here, and the average user is not so expert as the average Linux user ;)

For example, qblur, qcomp, and scenecut threshold are probably pretty good the way they are.
Yeah, I don't even know if I'm going to add them... mostly because I have no idea how they work :D

I can say that personally I don't even bother trying out changes in the interframe block size analysis flags because it never gives me any benefit and the only consistent result is less accurate ratecontrol.
I didn't know that. But IIRC Ateme's H.264 codec doesn't even implement the equivalent of PSUB8x8 because it's too slow and gives just a little improvement, so I even thought about disabling this flag by default... but maybe x264 uses fast heuristics for that?

BTW between "H264" and "AVC1" 4CCs our dear x264 chose... "X264" (and it cannot decode it yet!). Think all 3 should be added, with maybe AVC1 as default...

[snacky]

For example, qblur, qcomp, and scenecut threshold are probably pretty good the way they are.
Yeah, I don't even know if I'm going to add them... mostly because I have no idea how they work

Stolen from the mplayer manpage:

qblur=<0-99>
Temporal blur of the quantization parameter (default: 0.5).
Lower values allow the quantizer value to jump around more,
higher values force it to vary more smoothly.
qcomp affects a parameter of the (default) ratecontrol equation. Low values make the bitrate more constant; high values make the quantization parameter chosen more constant.

As for scenecut threshold: the encoder first tries to encode a frame as inter, but if a large number of I-blocks show up, it will just encode the frame as an I-frame. The scenecut threshold affects the percentage of I-blocks that will cause the encoder to make the frame an I-frame.

BTW between "H264" and "AVC1" 4CCs our dear x264 chose... "X264" (and it cannot decode it yet!).
No idea what you mean by this. The muxer is the app that places the fourcc in the header, not x264. Also x264 is not being used for decoding. If you're using ffdshow, it uses ffmpeg's h.264 decoder.

[bond]

small letter "avc1" is indeed the four letter name given to h.264 (or mpeg-4 avc) when stored in .mp4, as "mp4v" is used for mpeg-4 part2 streams
so i indeed think that "avc1" can be seen as the official fourcc given to h.264 in the mpeg-4 standard

anyways the mess is already here: dicas uses DAVC as fourcc, and vanguard uses VSSH, so these might also be offered in the dropdown list
still i think that avc1 indeed should be default in x264

[apart from that h.264 shouldnt be placed in .avi and shouldnt be encoded via vfw:
why not add the possibility to output smooth .mp4 files to the commandline encoder (a lib able to do that is available at mpeg4ip);
why not enjoy interoperability with neros, sorensons and envivios implementations (and virtually any h.264 implementation fully based on mpeg-4);
why not being able to port it to other platforms, like linux, by not using windows centric vfw stuff;
why not avoid upcoming hassles with storing b-frames, aso aso...?]

[virus]

Originally posted by snacky
No idea what you mean by this. The muxer is the app that places the fourcc in the header, not x264. Also x264 is not being used for decoding. If you're using ffdshow, it uses ffmpeg's h.264 decoder.
The current x264 GUI allows to enter the 4CC directly. XviD does the same... and if you change from X264 (the default) to H264 something changes (try decoding with ffdshow ;)) so I guess this param is still useful... :)

@bond:
I think ffdshow recognizes AVC1 (haven't tested it, just H264) with capital letters, but does it recognize avc1 lowercase?


also, further explanation about the GUI tabs. My idea was:

hopeless n00b -> use only the main tab
advanced user -> use the main tab and often just the 1st advanced tab, which includes the speed/quality options not contained in the main tab.

following this idea, I'm thinking about moving the deblock params to the 1st tab and move the GOV ones to the 2nd, since you'll probably want to tune the deblocking more often than changing the max keyframe distance... you see, in most cases you'll only work with 2 tabs that way. Remember that XviD uses 1 Main tab + 3 Prof@Lev tabs + 3 Advanced Tabs + 1 RC Tab for 2nd pass... it's not so easy to fit every useful option in a little space ;)

[bond]

Originally posted by virus
I think ffdshow recognizes AVC1 (haven't tested it, just H264) with capital letters, but does it recognize avc1 lowercase?i told milan to support small letter "avc1" and i think it does support it as small letter as ffdshow can connect to the 3ivx splitter which outputs small letter avc1

[virus]

Originally posted by bond
apart from that h.264 shouldnt be placed in .avi and shouldnt be encoded via vfw
it works, why not?

why not enjoy interoperability with neros, sorensons and envivios implementations (and virtually any h.264 implementation fully based on mpeg-4)
why not do as I always do with my XviD DVD rips: using AVI as a transitional container for video only, and then remuxing to MP4? We have VDub(Mod), no-one will ever add MP4 support to it so why not AVI (or maybe MKV)? You should push for an MP4 muxer that accepts H.264 streams instead... you'll get better chances to have it done ;)

why not being able to port it to other platforms, like linux, by not using windows centric vfw stuff
bond, it's the other way around ;)
right now x264 is "Unix-centric"... we need to port it to Windows using the most widely supported encoding interface under Win32, aka VfW :D

[Sirber]

Better use VFW than crappy cmdline app... (I'm not talking about producer :angry: )

[akupenguin]

Originally posted by Tommy Carrot
Disabled deblocking filter often gives better results at higher bitrates. At higher bitrates, deblocking is disabled anyway, just due to the QP adaptive strength. You might want to adjust the strength parameters, but I would never completely disable deblocking, other than when it disables itself.

The analysis flags are supposed to be a tradeoff between speed and quality. Although there is no big speed penalty when all is enabled, i'm not sure if this is the right behaviour, this can be a bug imo. psub16x16 and i4x4 should come at a significant speed/quality tradeoff. psub8x8 is only tried if 8x8 is the best psub16x16 mode, which is only around 5-10% of the blocks in my tests, so it doesn't cost much speed. (I guess this counts as a "fast heuristic")

And I like my mencoder, so I won't let my opinions get in the way of you all designing a gooey interface.

[yaz]

Originally posted by Sirber
Better use VFW than crappy cmdline app... khmm ... mencoder works pretty fine producing the best output as regards the h264 implementations i've been able to test ... if u meant that :-)

ffdshow accepts avc1, vssh, davc and h264 as 4cc and associate them with h264 content. there are some further 4cc signed as other mpeg4 (e.g. 3ivx) the 4cc mp4v is also there but it's associated with divx4(???)
however, this all is just playing with 'letters' as the decoder only selectable is libav whatever 4cc is considered. pls, note, all this 4cc business come into sight if u wrap your video into avi (as made by mencoder or vfw) and not into mpg or mp4.

the bests
y

ps. can anyone tell me what 4cc is accepted by the 'sigma' decoder (found and pointed by bond sw in this thread) ? i'd like to test that too. thx!

[ivan_alias]

mencoder works pretty fine producing the best output as regards the h264 implementations

Where can I get a build of mencoder with x264 support? Has anyone put a build up anywhere?

ta'

[netchris]

yaz wrote :
mencoder works pretty fine producing the best output as regards the h264 implementations i've been able to test ... if u meant that :-)

What do you meen? Best output picture-wise? All the x264 implementations should have the same quallity since ffdshow and mencoder are just shells for the x264 codec (and they are both updated with the latest code).
Not to mention the x264 native vfw version itself (that is applied to the primary codec without any changes).

[pogo stick]

Originally posted by bond
apart from that h.264 shouldnt be placed in .avi and shouldnt be encoded via vfw: why not add the possibility to output smooth .mp4 files to the commandline encoder (a lib able to do that is available at mpeg4ip)...
Maybe it will be a good idea to make mencoder output mp4 files using mpeg4ip or GPAC stuff. I wonder, is it very hard to do? Or mencoder developers just don't care about mp4? And it seems like there are no tools yet that can work (in any way) with H.264 in mp4. Am I right? I heard that Ateme's muxer can mux H.264.mp4 and aac.mp4, but it's not available for everyone.
Originally posted by Sirber
Better use VFW than crappy cmdline app...
But I'm sure you know what is the good side of command line programs. Someone can write nice GUI for it. Like there are many for producer.

[yaz]

@ivan_alias
mencoder : i tried celtic's build. it's available on his site (as noted sw above)

@netchris
All the x264 implementations should have the same quallity just as u wrote; should be. but they are not. just have a look into the ffdshow development thread. ffvfw produces artifacts not seen with mencoder. ok, it's a problem of the implementation but that's what a user see (mencoder is ok, ffdshow produces crap) and nobody bothers about that the core is the same.
so, speaking as correct as i can, i've been able to produce the best-looking output with mencoder ... so far.

btw, what decoder do u use ? i'm with vss now (that was suggested for x264 time ago) but i'm ready to change if anyone suggests sg better.

the bests
y

[Tommy Carrot]

Originally posted by yaz
just have a look into the ffdshow development thread. ffvfw produces artifacts not seen with mencoder.
In my knowledge this has been solved, the problem was not with the implementation, but with the compiler settings (and probably with the inaccuracy of the intel compiler).
btw, what decoder do u use ? i'm with vss now (that was suggested for x264 time ago) but i'm ready to change if anyone suggests sg better.

I use ffdshow. It offers much more features, especially the OSD and the visualizations functions can be useful, and the playback requirement is quite low too.

[KpeX]

AFAIK there is h.264 > mp4 muxing being worked on in both mpeg4ip and gpac. I doubt MP4 support would be added to mencoder. As long as the output is playable in mplayer I don't think the devs are interested in other containers.

Although vfw is outdated a good vfw interface will be useful to x264 development. Where would xvid be without the thousands of vfw users that tested it along the way? x264 in mencoder is great, but the exposure and testing will increase exponentially with an up to date, easy to use vfw interface.

[bond]

i would prefer a commandline tool with nice gui, but well i am no dev.
still the most important thing is that x264 gets further developed, no matter what interface/tool is used :)

[yaz]

Originally posted by Tommy Carrot
...ffdshow ...In my knowledge this has been solved, the problem was not with the implementation, but with the compiler settings (and probably with the inaccuracy of the intel compiler).after some short tests with the latest ffdshow i must say nothing's solved. i got the same crappy output :-( (see my comments in the other thread)
y

[Tommy Carrot]

Originally posted by yaz
after some short tests with the latest ffdshow i must say nothing's solved. i got the same crappy output :-( (see my comments in the other thread)
y

By solved i meant celtic_druid's x264 dll build #8 (it was discussed a few days ago in the ffdshow thread), which is free from this bug.

[yaz]

Originally posted by Tommy Carrot
By solved i meant celtic_druid's x264 dll build #8 (it was discussed a few days ago in the ffdshow thread), which is free from this bug. thx, TC ! it really worx.Originally posted by Tommy Carrot
I use ffdshow. It offers much more features, especially the OSD and the visualizations functions can be useful, and the playback requirement is quite low too.i made some quick tests which say vss is still better for x264. i encoded the duell scene from the 'last flight of the osiris' with subq=0-5 and with ffdshow the quality improvement was fairly visible. however, i noticed a kinda stepwise degradation on slowly moving, fine texture objects (y'know, that long stripes hanging/flipping in the fore- and background) which i always observe when my xvid encodes are decoded with libav. when changed to vss all these craps were gone and even the halfpel encode seemd amazing !
then i repacked the stream into mp4 and gave a go to xvid (that's my default mp4v decoder) and that seemed to be ok as well.
so, my experience tells that ffdshow is far not the best for x264 at the moment.

the bests
y

[snacky]

Does anyone know if it's even possible with current ffdshow to get the REQUESTED quants when encoding with x264?

I don't have a dedicated windows box, but in all cases I've seen, you get the ridiculous "looping quants" problem I mentioned earlier. IMO this renders ffdshow mostly useless as an x264 frontend.

[Tommy Carrot]

Originally posted by snacky
Does anyone know if it's even possible with current ffdshow to get the REQUESTED quants when encoding with x264?

I don't have a dedicated windows box, but in all cases I've seen, you get the ridiculous "looping quants" problem I mentioned earlier. IMO this renders ffdshow mostly useless as an x264 frontend.
This is a strange bug indeed.
http://www.fw.hu/carrotland/blockquants.jpg
As you see in the picture, most macroblocks got the requested quant, but MBs of the upper left corner are somehow underquantized, and the QP is constantly changing, giving the "looping quants" problem you mentioned. But the largest part of the video has the right quantizer.

[snacky]

Don't look at the per block quants, look at the per frame quants. This WILL result in ludicrous filesizes if a scene change happens to occur at a point where ffdshow has managed to request a quant of zero. In any case, it's very frustrating - there is really no way to get reasonable quants, OR the bitrate you want, OR the constant quant you want,.... This completely rules out ffdshow for generating watchable x264-encoded clips, and imo it throws a big monkeywrench in the works even if all you want to do is to test some options, since the main determinant of quality/filesize/encoding time/decoding time is always going to be the number of absurdly underquantized macroblocks.

[Tommy Carrot]

Come on man, most macroblocks always get the requested quant, except a few in the upper left corner. Yes, this is a strange and somewhat bothering bug, but 6-7 macroblocks cannot have a big influence in the bitrate.

[snacky]

No, it's essentially coincidence that any blocks get the requested quant. Insert 27 black frames before the video and see what happens.

[Tommy Carrot]

True, but it only happens with _perfectly_ black frames, and in that case it doesn't matter how do you quantize it, the frame wont be bigger. When there is any content on it, then most blocks will be correct, except a few in the upper left corner.

[snacky]

You're not understanding.

Here's an example of what ffdshow is doing.

Any I-blocks in frame 1 have quant 27.
Any I-blocks in frame 2 have quant 26.
Any I-blocks in frame 3 have quant 25.
[...]
Any I-blocks in frame 27 have quant 0.

The only reason your clip didn't have horrendously absurd quants is because you were lucky enough to get mostly predicted/skip blocks at the moment when ffdshow was choosing unreasonable quants. The upper left corner just happened to be affected by motion or something at a point where ffdshow had rolled on down to quant=6. 6, btw, is so insanely low as to be completely pointless for most ordinary purposes. Anyway, if you keep trying, you will end up with videos loaded with tons of quant-0 blocks, and that's just completely ridiculous.

[Tommy Carrot]

I've never experienced that (except in total black frames, where it doesn't count anyway), and i made a lot of test encodings with different characteristics. The majority of the blocks _always_ get the selected quantizer, no exception there. The only problematic part is the upper left region.

Don't get me wrong, it does bother me as well, all i want to say is that it doesn't make ffdshow completely unusable.

BTW, i've only tested fixed quantizer mode. If you refer to 2-pass mode, then you're probably right, i don't know nothing about it.

edit: it's probably worth to mention that i use ffdshow 20041003 build with celtic_druid's x264 build #8.

[unmei]

With the 20041003 ffdshow i experience what snacky observed as well. It is true in actual scenes as far as i have seen only the upper left corner is affected, but in the opening (title etc) i see this counting down of quantisers. It is always the top part down to where the text starts.
See this capture (146KB png) (http://homepage.hispeed.ch/mieru/doom9/x264/snapshot20041016151026.png).
The encode is "constant quantiser 18", but 18*51/31 is ~29, so the other quantisers are always correct taking that the selectable scale of 31 in the GUI is mapped to h.264 scale of 51.

But Tommy Carrot is probably right that these underquantised black blocks do not generate much too big frames..

[Mug Funky]

actually, quantscale seems to map like this:

h264_quant = int(ffd_quant*52/32)

remember 0 is still a quant.

ffdshow will round down, so there's a few target quants that just can't be set.

[unmei]

Thanks for the clarification, mug funky. It's not a big difference, but still good to know :)

[Yong]

Can someone suggest me a good encoding parameter(x264 and ffdshow h264)?
Thanks!

[unmei]

Yong, this sounds like you want to do actual backup in x264 :scared:
I would not recommend backing up with x264 at this point, it is still too deep in development.
That aside, the initial parameters are quite good so you can just start from there and toggle one or the other feature on/off.

The most important setting is surely the mode, one pass quantiser and two pass are imo the ones to choose from. I always do one-pass quantiser, as even i do some full movie encodes in x264 i never meant to fit them to a exact size so far (as im not using them for backup and mostly delete them soon again).

The Quantiser is a very sensitive parameter, in my experience in the mid-range, a decrease of 2 often almost doubles bitrate. Some example quantisers for full DVD resolution (anime) i got around 800-1100 kbit at q=14 and around 350 kbit at q=18. As with all codecs this depends much on the content, but i think quantisers around 12-18 are a good starting point.

For very high bitrates you could try disabling the loop filter, it will result in a bit less smooth/more block endangered picture. Cabac should be left enabled unless you do not want to use it due to its patented state. I read somewhere CABAC were shown to be 10% more effective in most cases than the CAVLC that would be used if you uncheck the CABAC box.

In the motion estimation tab you could play with the subpel refinement mode. I think the ones on top are the faster, the ones at the bottom the slower/better quality. However others reported artifacts with the "more iterations" mode. I did not experience these, but in this mode for me VDM crashed after 2150 frames (simply vanished without notice) :eek:
I had good experiences both with (halfpel on all, qpel on winner) and (qpel on all). Both did not produce artifacts and completed a shorter full movie (~75000 frames) sucessfully.
Still in the same tab, i would not touch the analiser flags unless you are up to some serious testing. All, on sounds good to me - just let it work to make hopefully the best estimation.
Reference frames should also probably stay at 1. You can try low other numbers though, but it seems higher numbers were inefficient and can increase the bitrate (reduce quality in bitrate mode respectively).

Anyway, i just fired up the config tab and tried to say something to every relevant parameter. Its not some proven recommended settings list and open for discussion/invalidation for sure.

[bond]

Originally posted by Yong
x264 and ffdshow h264also note that the h.264 encoder in ffdshow actually is x264 :)

[akupenguin]

Originally posted by unmei
The Quantiser is a very sensitive parameter, in my experience in the mid-range, a decrease of 2 often almost doubles bitrate. Some example quantisers for full DVD resolution (anime) i got around 800-1100 kbit at q=14 and around 350 kbit at q=18.
It's supposed to double the bitrate every 6 QP. But ffdshow has that funky 32->52 scaling going on.

Cabac should be left enabled unless you do not want to use it due to its patented state.
Just about all of H.264 is patented. You certainly can't get away from that just by disabling some options.

[Tommy Carrot]

Originally posted by akupenguin
But ffdshow has that funky 32->52 scaling going on.

Milan has fixed the quantizer scaling today, the scale range will be 0-51 in the next build.

[virus]

I've investigated a bit the "b0rked output with gcc -O2 and subpel ref > 0" problem discussed in the ffdshow thread a few days ago; celtic_druid posted his build #8 for ff_x264.dll compiled with -O and we know it works.

Well, I successfully managed to compile ff_x264.dll myself with -O3 (and all the other gcc flags in the default Makefile) but disabling MMXEXT code and got a build which produces bit-identical results with celtic_druid's one. Of course, mine is ~40% slower due to the lack of ASM optimizations. I'm using MinGW (gcc 3.2.3).

Maybe something is wrong in the way gcc interacts with nasm code? does compiling with MMXEXT and -O3 work with mencoder?

[Sagittaire]

What is the best way for testing x264?
- x264 vfw?
- ffdshow with build #8 for ff_x264.dll?

And best setting for you?
- more iterations or qpel on all?
- IDR interval?

[hellfred]

I think that akupenguin mentioned using mencoder in the ffdshow development #2 thread ( in this section of doom9 forum), because it allows to set more options than the other solutions. Update work on the vfw interface was started, don't know if the latesed options are available already. For ffdshows x264 you should try to get hold of a celtic_druid's x264 dll build #8 and replace the one that was installed from sourceforge's ffdshow build, as there were some problems with gcc -O2 optimization flag in the sourceforge ffdshow build of this file. See x264 development thread for more info. BTW, celtic_druid never put up a link to build #8, get yourself the links to builds with lower numbers and edit it to get #8.

Hellfred

P.S.: I did not verify that all infos given are still up to date. But this should at least help you getting started.

EDIT: Celtic_Druid posted the dlls in the ffdshow development #2 thread.
The link can be found on its 7th page, or just click here (http://celticdruid.no-ip.com/test/ff_x2648.7z).

[akupenguin]

Originally posted by Sagittaire
What is the best way for testing x264?
Yes, I use mencoder. But I've never tried ffdshow (I'm on Linux), so I can't say what's better.

"more iterations" is always the best mode. The only reason it's optional is the speed tradeoff.

I think that IDR interval = 1 is the best, for now. A larger IDR interval gives the same seeking penalty that you get from a large keyframe interval, but without as much compression gain. That will change when we get around to implementing adaptive IDR, but for now there's no benefit in IDR interval > 1.

[gldblade]

I think the previously described quantizer looping problem is best shown with a screenshot taken directly from ffdshow:

http://web.mit.edu/ctan/www/codecs/quantLoops.PNG
http://web.mit.edu/ctan/www/codecs/quantLoops2.PNG

I do believe that the white lines represent frame quantizers, in which case there is clearly something unusual going on.

*EDIT*
Just to make sure that the white lines do in fact represent quantizers, I decided to put x264 into constant quantizer mode. A look at the graph reveals that the white lines do in fact represent quantizers. This implies something is pretty wrong with constant bitrate mode. Rate control perhaps?

[snacky]

Hey, I'd almost given up on this thread, then you came along.

Yes, current ffdshow always does this. There is no way to even get constant quants with it, because of this hideous bug that causes frame-level quants to loop in exactly the manner your graphs show.

[gldblade]

Hm, are you sure about not being able to get constant quants? Maybe ffdshow is reporting this to me wrong, but:

http://web.mit.edu/ctan/www/codecs/quantConst.PNG

This suggests ffdshow works at least partly.

*EDIT*
In addition, after actually watching the video with quantizers overlaid on top, I have come to the same conclusion that this bug doesn't render ffdshow completely useless. As others have said, while the bug is disturbing, it shouldn't have too much of an effect.

So basically I have contributed nothing new here, oops sorry guys :P

[Yong]

Thanks unmei and bond for the replies.;)
@unmei:
I'm not going to backup my video using the x264, it's still to buggy right now, am i right? I just can't decided which setting or encoder is right for me.

@bond:
I know ffdshow is using the x264 code, but ffdshow h264 have more tweaking option(or faster, or something else...) than the x264vfw Core 11.:cool:

[yaz]

Originally posted by Yong
Thanks unmei and bond for the replies.;)
@unmei:
I'm not going to backup my video using the x264, it's still to buggy right now, am i right? no, you're wrong :-) i've never had such artifacts you mentioned either with mencoder or with celtic's ff_x264. i'm sure it's an ffdshow bug. maybe that compiler issue again, mentioned in the ffdshow thread(?)Originally posted by Yong
I know ffdshow is using the x264 code, but ffdshow h264 have more tweaking option(or faster, or something else...) than the x264vfw Core 11.:cool: what do you mean by this ???
y

[Yong]

@yaz:
Compare with the ffdshow h264, [x264vfw core 11] only have 6 options to "tweaking" IIRC.
I still don't how two use two pass(may be need to use the libavcodec stats file.). May be not need two pass encodeing, one pass already can produce good result.:cool:

mencoder with h264 encoding? plz tell me where it's! I'm tired with the VDMod "Parsing MPEG video" slow process..

Thanks for yaz reply and correct me,:D
i'm a newbies:) Still need sometime to learn how to encode video when using ffdshow, Xvid and h264.

[akupenguin]

Originally posted by Yong
I know ffdshow is using the x264 code, but ffdshow h264 have more tweaking option(or faster, or something else...) than the x264vfw Core 11.
That just means x264vfw hasn't been updated in a while. (Virus is working on it, but nothing released yet.)
ffdshow uses x264 core 51 or so.

[yaz]

Originally posted by Yong
... Compare with the ffdshow h264, [x264vfw core 11] only have 6 options to "tweaking" IIRC ... see akupenguin's comment
Originally posted by Yong
I still don't how two use two pass... find milan's comment in ffdshow#2 thread on page 3, cited by virus (crosspost's not allowed) it's quite easy.Originally posted by Yong
mencoder with h264 encoding? plz tell me where it's! find an up-todate compile of mencoder, x264 is included. it offers the most complete option-set but u must pal up with the cli.
i've been using celtic's compiles but ... y'know :-(((Originally posted by Yong
i'm a newbies:) Still need sometime to learn how to encode video when using ffdshow, Xvid and h264. no blame :-) i'm not a noob but still i learn new things all day. y'know, living is learning.

the bests
y

[celtic_druid]

mplayer/mencoder Athlon XP Build (http://celticdruid.no-ip.com/xvid/mplayer/mplayer2004.10.22.7z)
mplayer/mencoder Pentium4 Build (http://celticdruid.no-ip.com/xvid/mplayer/mplayer2004.10.22P4.7z)
mplayer/mencoder Athlon TBird Build (http://celticdruid.no-ip.com/xvid/mplayer/mplayer2004.10.22tbird.7z)

Builds updated. There was a problem with x264 encoding.

[virus]

Originally posted by akupenguin
(Virus is working on it, but nothing released yet.)
Right now, I'm not working on anything. I'm still waiting for an answer by the devs (9 days...). If they don't ever care to talk to ppl that offer help, I don't see why I should waste my time with them.
I support other (not videocoding-related) projects and they for sure deserve my help much more. Sorry.

virus

[RadicalEd]

Originally posted by celtic_druid
mplayer/mencoder Athlon XP Build (http://celticdruid.no-ip.com/xvid/mplayer/mplayer2004.10.20.7z)
mplayer/mencoder Pentium4 Build (http://celticdruid.no-ip.com/xvid/mplayer/mplayer2004.10.20P4.7z)

Any chance for an unoptimized (or MMX-only) build for poor suckers with old-skool Athlons? :O

[RadicalEd]

mplayer2004.10.21tbird.7z

Awesome :D Thanks!

[celtic_druid]

I have updated the compiles. Anyone having problems with x264 encoding should grab the new build.

[aketon]

Can anyone please tell me what kind of files are .7z and how can I use them?:confused:
Thanks!

[Tommy Carrot]

http://www.7-zip.org

[aketon]

Very interesting!

Thanks!

[ivan_alias]

Thanks to Celtic_druid for the builds :)

I must ask though, does anyone have a mirror of these builds? They take over 40 mins to download!!

I'm only getting 1.3KB/s :(

[celtic_druid]

WinRAR also supports 7zip files, that is if you have the latest version.

If someone wants to mirror anything, then yes please do.

[pogo stick]

Originally posted by celtic_druid
mplayer/mencoder Athlon XP Build (http://celticdruid.no-ip.com/xvid/mplayer/mplayer2004.10.22.7z)
mplayer/mencoder Pentium4 Build (http://celticdruid.no-ip.com/xvid/mplayer/mplayer2004.10.22P4.7z)
mplayer/mencoder Athlon TBird Build (http://celticdruid.no-ip.com/xvid/mplayer/mplayer2004.10.22tbird.7z)

Builds updated. There was a problem with x264 encoding.

Thank you for P4 compile, Celtic Druid! 2004.10.22 version seems to work. :)
Is there a way to open AVS files with mencoder? I tried to use "makeAVIS.exe" from ffdshow, but mencoder says: "Cannot find codec matching selected -vo and video format 0x53495641." And docs doesn't say anything about AviSynth.

[ac-chan123]

MPlayer have no avs support. mplayer is a linux player, wich is also availe for win32, but the development ist mostly on linux. So there are not so much win32 spezific things in it.

[akupenguin]

Originally posted by pogo stick
Is there a way to open AVS files with mencoder?
MEncoder itself doesn't support AVS. MakeAVIS doesn't work because MEncoder doesn't use VfW.
I wrote an AVS decoder program which I cross-compiled and run under Wine, but who knows, it might work under Windows too. AVS2YUV (http://students.washington.edu/lorenm/src/avisynth/avs2yuv/)

[yaz]

Originally posted by pogo stick
... Is there a way to open AVS files with mencoder? I tried to use "makeAVIS.exe" from ffdshow, but mencoder says: "Cannot find codec matching selected -vo and video format 0x53495641." And docs doesn't say anything about AviSynth.yep, no avisynth support by def., but u can make a workaround with makeavis. for using the fake avi generated by that u must add ffsdhow to the codecs.conf file. drop sg like this intovideocodec makeavis
info "FFdshow makeavis"
status untested
fourcc AVIS
driver vfw
dll "(path)/ffdshow.ax" ; path=location of ffdshow.ax from root up
out YV12 ; add further formats by comma separated


i've just tried and it worked fine.

the bests
y

[pogo stick]

Both methods don't work for me. :(
avs2yuv's outputted files look green in mplayer or after encoding with mencoder.
makeAVIS files are causing this error:

Opening video decoder: [vfw] Win32/VfW video codecs
Loading codec DLL: 'C:\Program Files\ffdshow\ffdshow.ax'
Loaded DLL driver C:\Program Files\ffdshow\ffdshow.ax at 10000000
ICDecompressGetFormat failed: Error -2

Fake avis are also giving error in VirtualDubMod and can not be decoded.
Opening in DShow and using AviSource() with VDub works.
It's strange.

[Sagittaire]

x264 seem to have a very good potential too ...

http://jfl1974.free.fr/Video/x264vsVP6-1000.JPG

Average PSNR
H264 : 44.7337 dB
VP6 : 44.3975 dB
x264 : 44.2624 dB
RV10 : 44.0334 dB
WMV9 : 43.7891 dB
XviD : 43.6912 dB
DivX5 : 43.0575 dB

Overall PSNR
H264 : 44.1604 dB
VP6 : 43.9286 dB
x264 : 43.6708 dB
RV10 : 43.5277 dB
WMV9 : 43.3891 dB
XviD : 43.2531 dB
DivX5 : 42.4873 dB


but visualy high block flicking for high quant encoding ... :(

[Sirber]

x264 is still CBR right?

[Sagittaire]

2 pass with ffdshow and libavcodec/h264 stat:
- first pass mode quant
- second pass mode bitrate

I make first pass with same average quant (approximative evaluation with little sample) than second pass -> very better RC and very constant quality

[ak]

Originally posted by pogo stick
makeAVIS files are causing this error:

Opening video decoder: [vfw] Win32/VfW video codecs
Loading codec DLL: 'C:\Program Files\ffdshow\ffdshow.ax'
Loaded DLL driver C:\Program Files\ffdshow\ffdshow.ax at 10000000
ICDecompressGetFormat failed: Error -2

Probably old ffvfw.dll can do the trick, put it in mplayer codecs dir and edit codecs.conf. And maybe create fake avi with makeavis.exe from ffvfw bundle, not sure if it matters though.

I was trying .ax once and it didn't work for me either, although old ffvfw used to work, IIRC.

[yaz]

Originally posted by pogo stick
... ICDecompressGetFormat failed: Error -2 ... Fake avis are also giving error in VirtualDubMod and can not be decoded.
Opening in DShow and using AviSource() with VDub works.
It's strange. imho

1) its a colorspace misery. try
- destall all ffvfw (a time ago this whole makeavis business was made by ffvfw but now it's merged into ffdshow) and install ffdshow041012 (or newer:-) make sure makeavis is ticked!
- check whether vidc.avis is set in the registry (needed not by mencoder but by any ds player)
- when making fake avis do not(!) force any color ouput format (let mencoder convert it if needed). serve audio only if u got it in the source (mencoder will check it but why to make it risky? :-)
- try playing the fake avi. if everything went right it should play fine in ds (& mencoder will accept it)
if not ... try the 'workaround of the workaround'.
- find and old ffvfw (say, 031113 made me the trick).
- install
- copy ffvfw.dll (from the system dir) and libmplayer.dll (from the install dir) besides(!) mencoder.exe.
- change the codecs.conf's 'dll' item to ffvfw.dll
- uninstall ffvfw (& put back ffdshow)
i made avisynthing for months (until makeavi support was switched back) this way & worked fine.

2) some filters, filter-chains or functions (avis) may cause serving misery. if nothing works from the aboves try building your script filter by filter.

the bests
y

[yaz]

Originally posted by Sagittaire
x264 seem to have a very good potential ... sure! what it produces is really amazing. on some scenes it beats xvid (which is the etalon for me:-) definitely.
Originally posted by Sagittaire
... but visualy high block flicking for high quant encoding ... for playback i suggest vss decoder, as ffdshow makes some artifacting on fine texture and also on wide flat surfaces. maybe, that's what u experienced.
btw, how did u make that psnr tests ? & what is h264 ?

the bests
y

[pogo stick]

Thanks for helping, ak, yaz! :)
It seems like colorspace thing. I was forcing YV12 in makeAVIS. Without forcing it worked. With ffdshow-20041012-sse2 picture was flipped. So I used ffvfw-20031028 (the latest I could find) and it's OK. But there are few things that I don't understand:

Opening video decoder: [vfw] Win32/VfW video codecs
Loading codec DLL: 'codecs\ffvfw.dll'
Loaded DLL driver codecs\ffvfw.dll at 10000000
VDec: vo config request - 704 x 544 (preferred csp: Packed YUY2)
[PP] Using codec's postprocessing, max q = 9.
Could not find matching colorspace - retrying with -vf scale...
Opening video filter: [scale]
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is undefined - no prescaling applied.
SwScaler: using unscaled Planar YV12 -> Planar YV12 special converter
x264 [warning]: rc buffer size 0 too small
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2
Selected video codec: [makeavis] vfm:vfw (FFdshow makeavis)

If my source (just cropped and trimmed MPEG2 file) is YV12 then why it shows YUY2? Why it doesn't find matching colorspace, use scale filter and use converter? And what is codec's postprocessing? Also warning about rc buffer is little bit confusing. I didn't change default ratecontrol setting and it's fixed quantizer first pass so as I understand it shouldn't matter. :confused:

[akupenguin]

I don't know why forcing YV12 didn't work, or why YUY2 is preferred.

It needs a "unscaled Planar YV12 -> Planar YV12 special converter" because x264 (or at least the mencoder wrapper for x264) supports I420 but not YV12. The only difference is the order of image planes in memory, so the "scaler" swaps a couple of pointers and all is good.

rc buffer is indeed irrelevant to constant qp mode. I just submitted a patch to remove that warning.

[yaz]

Originally posted by pogo stick
...With ffdshow-20041012-sse2 picture was flipped. So I used ffvfw-20031028 (the latest I could find) and it's OK ...
yep ... joke from ffdshow. sorry, i forgot to mention it. no problem, anyway. just put a flipvertical() at the end of your script & use ffdshow041012. (it's clean, dry & safe :-)
Originally posted by pogo stick
... If my source (just cropped and trimmed MPEG2 file) is YV12 then why ... :confused: so am i. it's spoken exactly the same way whatever input/output combination i've tried. don't bother, it doesn't hurt. it seems as if this mantra would be needed for proper operation of mencoder :-)))

the bests
y

ps celtic_druid kindly provided an update of mencoder. it's worth to try. x264 seems better than ever.

[pogo stick]

OK. Than colorspace changing is not a big problem. But is postprocessing seems strange. Is it how it should be?
Originally posted by yaz
celtic_druid kindly provided an update of mencoder. it's worth to try. x264 seems better than ever.
Great! Is there something new?

[pogo stick]

Originally posted by akupenguin
MEncoder itself doesn't support AVS. MakeAVIS doesn't work because MEncoder doesn't use VfW.
I wrote an AVS decoder program which I cross-compiled and run under Wine, but who knows, it might work under Windows too. AVS2YUV (http://students.washington.edu/lorenm/src/avisynth/avs2yuv/)
After installing Helix YV12 / I420 VFW codecs avs2yuv started to work without problems (no green video). But mencoder with avs2yuv doesn't work:

Reading from stdin...
success: format: 0 data: 0x0 - 0x0
total frames: 896
YUV4MPEG2 file format detected.
YUV4MPEG2 Video stream 0 size: display: 384x208, codec: 384x208
VIDEO: [YV12] 384x208 12bpp 23.976 fps 0.0 kbps ( 0.0 kbyte/s)
[V] filefmt:12 fourcc:0x32315659 size:384x208 fps:23.98 ftime:=0.0417
Opening video filter: [expand osd=1]
Expand: -1 x -1, -1 ; -1 (-1=autodetect) osd: 1
==================================
Opening video decoder: [raw] RAW Uncompressed Video
VDec: vo config request - 384 x 208 (preferred csp: Planar YV12)
Could not find matching colorspace - retrying with -vf scale...
Opening video filter: [scale]
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is undefined - no prescaling applied.
SwScaler: using unscaled Planar YV12 -> Planar YV12 special converter
x264 [warning]: rc buffer size 0 too small
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2
Selected video codec: [rawyv12] vfm:raw (RAW YV12)
==================================
Writing AVI header...
ODML: vprp aspect is 16384:8874.

Flushing video frames

Writing AVI index...
Fixing AVI header...
ODML: vprp aspect is 16384:8874.

Video stream: -1.#IO kbit/s (-2147483648 bps) size: 0 bytes 0.000 secs 0 frames
x264 [info]: analyse=0(0ms) encode=0(0ms) write=0(0ms) filter=0(0ms)
Output error: wrote only 77546 of 79872 bytes

I just thought that maybe something else is missing in my system.
"Reading from stdin..." in mencoder and "The outfile may be "-", meaning stdout" in avs2yuv.
What is std?

I am sorry that about talking too much about mencoder in x264 thread. But it is very connected now. And I fell much more comfortable encoding in mencoder then in virtualdub.

[ak]

Try adding -rawvideo on:w=<width>:h=<height>:yv12 to cmdline.

Yeah and 'std' means standard, afaik.

[akupenguin]

Originally posted by ak
Try adding -rawvideo on:w=<width>:h=<height>:yv12 to cmdline. That won't work. Or rather, it should display something, but not what you want: avs2yuv outputs yuv4mpeg (yv12 with headers), not raw yv12. Anyway, you can see that mencoder correctly identified the video, the problem is in the pipe.

Output error: wrote only 77546 of 79872 bytes Someone in the Avisynth under Linux (http://forum.doom9.org/showthread.php?s=&threadid=81793) thread had the same problem. I couldn't reproduce it. His workaround was to use fifos, but those don't exist in Windows.

[ak]

Oh boy, and was mixing them all the time. Going to rtfm.

[pogo stick]

Originally posted by ak
Try adding -rawvideo on:w=<width>:h=<height>:yv12 to cmdline.
I don't know what is it, but I really like how it looks!
It's like train of distorted video moving from left to right!
Not really useful, but fun! :)

[ak]

Originally posted by akupenguin
Anyway, you can see that mencoder correctly identified the video, the problem is in the pipe.

Someone in the Avisynth under Linux ("http://forum.doom9.org/showthread.php?s=&threadid=81793) thread had the same problem. I couldn't reproduce it. His workaround waas to use fifos, but those don't exist in Windows.
Yeah, something confuses mencoder in piped avs2yuv output, mpeg2enc as well for that matter. They give this on first frame:
<mencoder>: error reading frame bad header magic
<mpeg2enc>: Error reading frame header (0): codebad header magic!

Ffmpeg's yuv4mpegpipe works with both otoh, so does encoding using fifo.

[movmasty]

Originally posted by snacky
In any case, it's very frustrating - there is really no way to get reasonable quants, OR the bitrate you want, OR the constant quant you want,.... This completely rules out ffdshow for generating watchable x264-encoded clips, and imo it throws a big monkeywrench in the works even if all you want to do is to test some options, since the main determinant of quality/filesize/encoding time/decoding time is always going to be the number of absurdly underquantized macroblocks.
i set a min Q of 4 and ffds kept using 1,2,3....

and i found that gives me half the bitrate i set, so to have 600kb i have to set 1.200kb...

[hellfred]

Originally posted by movmasty
i set a min Q of 4 and ffds kept using 1,2,3....

and i found that gives me half the bitrate i set, so to have 600kb i have to set 1.200kb...
Just get yourself to use mencoder for encoding to x264. It is not that hard to compile it for yourself, and once set up, you can easily compile the very latest x264 and link to it.
Steps involved:
Dl and install mingw and msys packages from www.mingw.org.
(First msys and than mingw into /mingw of msys root directory)
Dl nasm source. Unpack it (e.g. in your MSYS home directory /home/<loginname>) and compile it in MSYS using
"/.configure && make && make install"
Dl and compile x264 source from www.videolan.org using a windows svn client from http://subversion.tigris.org/ and the command line given on the vlc html page.
"cd x264/build/cygwin && make"
Afterwards copy the libx264.a and x264.h to /mingw/lib and /mingw/inclode:
cp bin/libx264.a /mingw/lib ;cd ../..; cp x264.h /mingw/include
You may have to edit the x264.h file to include stdargs.h:
...
#define _X264_H 1
#include <stdarg.h> //<- Add this
#define X264_BUILD 0x000b
...

Now downlad mplayer cvs source from mplayerhq.hu.
Get yourself the daily CVS snapshot source from the download page
Unpack it in MSYS and change into it using
tar xfj MPlayer-current.tar.bz2
cd MPlayer-2004xxyy
where xxyy will be the month and date of the day you have downloaded MPlayer-current.tar.bz2.
./configure
At the end of the summary you can check that x264 is listed under Codecs in the section, which should happen automatically when you copied the x264.h and libx264.a file to the appropriate directoris.
Enabled optional drivers:
Codecs: libavcodec ... x264

Then just type
make && make install
and you are done.
From then on you can use the command lines in the mencoder + x264 thread as a start to experiment with the codec. If you just can't get over using VDubMod for filtering/editing the source, output to some lossless codec from VDubMod and use that as imput for mencoder.
Only drawback of MSYS that i found up to now is that man is missing, so you have to find youself an up to date html man page for learning the x264encopts on the net.

Hellfred

[ak]

Regarding pipes, I remembered there was something similar with another program,
so this one here should work: http://4nykey.nm.ru/tmp/

[akupenguin]

I managed to find a Windows box and reproduced the piping bug: It occurs whenever the frame contains a byte 0x1A. (Ascii name "substitute", treated as EOF by Windows.) However, the stream does not translate \n to \r\n, so it isn't just the normal textmode corruption.
ak's patch ( "setmode(fileno(yuv_out),_O_BINARY);" ) doesn't help. It fixes "avs2yuv foo.avs - > file", but not "avs2yuv foo.avs - | mplayer -". For that matter, it isn't just my program that fails; "cat foo.avi | mplayer -" also dies on Windows.
Still, fwiw, I have updated avs2yuv to use binmode stdout.

... I don't like systems where eof() returns true when you aren't at the end of the file, even in textmode. So until further notice, I will continue running avs2yuv under Wine, because it's better than Windows.

[Leak]

Originally posted by akupenguin
... I don't like systems where eof() returns true when you aren't at the end of the file, even in textmode. So until further notice, I will continue running avs2yuv under Wine, because it's better than Windows.

I have the nagging feeling that all this will suddenly start to work as soon as it's done in a Cygwin bash or zsh, as opposed to CMD.EXE...

np: Poto & Cabengo - Life In San Diego (Poto & Cabengo)

[ak]

Originally posted by akupenguin
ak's patch ( "setmode(fileno(yuv_out),_O_BINARY);" ) doesn't help. It fixes "avs2yuv foo.avs - > file", but not "avs2yuv foo.avs - | mplayer -". For that matter, it isn't just my program that fails; "cat foo.avi | mplayer -" also dies on Windows.
Not much from me, that was pretty much copy'n'paste excersise.

FWIW, now 'avs2yuv foo.avs - | mplayer -' works for me in both wine and windows (using cmd.exe that is).

[hellfred]

Originally posted by ak
Not much from me, that was pretty much copy'n'paste excersise.

FWIW, now 'avs2yuv foo.avs - | mplayer -' works for me in both wine and windows (using cmd.exe that is).
Thank you a lot, ak
If I find some time, I will test it (Win98 Command.com && MSYS rxvt or cmd.exe from ReactOS project). I am looking forward to see if it works.

Hellfred

[hellfred]

No good on Win98
Both using MSYS rxvt console and cmd from ReactOS project, avs2yuv does not work. First is end of dir command in cmd.exe and second is the output of rxvt.
10-31-2004 7:34p <DIR> MPlayer-20041020
11-01-2004 8:44p 6,233 avs2yuv.exe
11-01-2004 8:51p 47 test.avs
34 Files 43,015,199 bytes
20 Dirs 3,249,659,904 bytes free

D:\Stefan\msys\1.0\home\Stefan>avs2yuv.exe test.avs -
Unknown error! Error code: 0xc1

D:\Stefan\msys\1.0\home\Stefan>avs2yuv.exe test.avs - | ..\..\mplayer_x264\bin\m
player.exe -
Unknown error! Error code: 0xc1
File not found -- Error executing CreateProcess()!!


D:\Stefan\msys\1.0\home\Stefan>

D:\Stefan\msys\1.0\opt\mplayer_x264\bin>avs2yuv.exe test.avs - | mplayer.exe -
Unknown error! Error code: 0xc1
MPlayer dev-CVS-041023-16:21-3.3.3 (C) 2000-2004 MPlayer Team

CPU: Intel Pentium III Katmai/Pentium III Xeon Tanner (Family: 6, Stepping: 3)
Detected cache-line size is 32 bytes
CPUflags: MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 0 SSE2: 0
Compiled for x86 CPU with extensions: MMX MMX2 SSE

Reading config file /opt/mplayer_x264/etc/mplayer/mplayer.conf: No such file or
directory
Reading config file D:/STEFAN/MSYS/1.0/OPT/MPLAYER_X264/BIN/mplayer/config
Reading D:/STEFAN/MSYS/1.0/OPT/MPLAYER_X264/BIN/mplayer/codecs.conf: Can't open
'D:/STEFAN/MSYS/1.0/OPT/MPLAYER_X264/BIN/mplayer/codecs.conf': No such file or d
irectory
Reading /opt/mplayer_x264/etc/mplayer/codecs.conf: Can't open '/opt/mplayer_x264
/etc/mplayer/codecs.conf': No such file or directory
Using built-in default codecs.conf.
font: can't open file: D:/STEFAN/MSYS/1.0/OPT/MPLAYER_X264/BIN/mplayer/font/font
.desc
font: can't open file: /opt/mplayer_x264/share/mplayer/font/font.desc
Using Windows native timing
Can't open input config file D:/STEFAN/MSYS/1.0/OPT/MPLAYER_X264/BIN/mplayer/inp
ut.conf: No such file or directory
Can't open input config file /opt/mplayer_x264/etc/mplayer/input.conf: No such f
ile or directory
Falling back on default (hardcoded) input config

Playing -.
Reading from stdin...


Exiting... (End of file)

D:\Stefan\msys\1.0\opt\mplayer_x264\bin>

Stefan@J5U7R1 /opt/mplayer_x264/bin
$ ls
avs2yuv.exe mplayer out.avi skript.sh test.avi
mencoder.exe mplayer.exe out.avi.bak sub_snow_q255.avi test.avs

Stefan@J5U7R1 /opt/mplayer_x264/bin
$ avs2yuv.exe
sh: ./avs2yuv.exe: Permission denied

Stefan@J5U7R1 /opt/mplayer_x264/bin
$ avs2yuv.exe test.avs
sh: ./avs2yuv.exe: Permission denied

Stefan@J5U7R1 /opt/mplayer_x264/bin
$ avs2yuv.exe test.avs - | ./mplayer -
sh: ./avs2yuv.exe: Permission denied
MPlayer dev-CVS-041023-16:21-3.3.3 (C) 2000-2004 MPlayer Team

CPU: Intel Pentium III Katmai/Pentium III Xeon Tanner (Family: 6, Stepping: 3)
Detected cache-line size is 32 bytes
CPUflags: MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 0 SSE2: 0
Compiled for x86 CPU with extensions: MMX MMX2 SSE

Reading config file /opt/mplayer_x264/etc/mplayer/mplayer.conf: No such file or directory
Reading config file D:/STEFAN/MSYS/1.0/home/Stefan/mplayer/config
Reading D:/STEFAN/MSYS/1.0/home/Stefan/mplayer/codecs.conf: Can't open 'D:/STEFAN/MSYS/1.0/home/Stefan/mplayer/codecs.conf': No such file or directory
Reading /opt/mplayer_x264/etc/mplayer/codecs.conf: Can't open '/opt/mplayer_x264/etc/mplayer/codecs.conf': No such file or directory
Using built-in default codecs.conf.
Font D:/STEFAN/MSYS/1.0/home/Stefan/mplayer/font/font.desc loaded successfully! (206 chars)
Using Windows native timing
Can't open input config file D:/STEFAN/MSYS/1.0/home/Stefan/mplayer/input.conf: No such file or directory
Can't open input config file /opt/mplayer_x264/etc/mplayer/input.conf: No such file or directory
Falling back on default (hardcoded) input config

Playing -.
Reading from stdin...


Exiting... (End of file)

Stefan@J5U7R1 /opt/mplayer_x264/bin
$

"Unknown error! Error code: 0xc1" and "sh: ./avs2yuv.exe: Permission denied"
Any idear what those mean? I will try your avs2yuv on some WinXP SP1 system soon, too.

Hellfred

[akupenguin]

Originally posted by hellfred
11-01-2004 8:44p 6,233 avs2yuv.exe I'm assuming you compiled that? None of my builds nor 4nykey's is that size.

Unknown error! Error code: 0xc1 I have no better idea what that is than you do.

sh: ./avs2yuv.exe: Permission denied That means that I packed the zipfile on Linux, where the exe, being a win32 binary, isn't executable. If unpacked on ntfs by a permission-aware unzip program, it will retain the non-executable status, which sh sees. I changed the zip to fix that, or you can chmod +x it.

[hellfred]

Originally posted by akupenguin
I'm assuming you compiled that? None of my builds nor 4nykey's is that size.

I have no better idea what that is than you do.

That means that I packed the zipfile on Linux, where the exe, being a win32 binary, isn't executable. If unpacked on ntfs by a permission-aware unzip program, it will retain the non-executable status, which sh sees. I changed the zip to fix that, or you can chmod +x it.
I have downladed that binary from 4nykey's side linked by ak. I will redownload it to see if it.

When doubleclicking the avs2auv on Win98, the OS will tell me that this is no win32 binary, and WinXP will tell me something about 16 Bit instructions. Sorry, as my OS is german, so are the messages, that i assume you will not understand therefore. So i did not copy & past them in here.

Msys tells me, that it can be executed:
Stefan@J5U7R1 /opt/mplayer_x264/bin
$ ls -l avs2yuv.exe
-rwxr-xr-x 1 Stefan unknown 6233 Nov 1 20:44 avs2yuv.exe

I will dl the executeable once more from 4nykey's side.

Hellfred

EDIT: Now i get an error message as the dll file AVISYNTH_C.DLL can not be found. I have latest AviSynth 2.5.5 installed and ffdshow 20041012 with all options checked. Where to get that file?

EDIT2: Found it in google and just downloading it.

EDIT3: Now it works, just a error in kernel32.dll at the end of playback.
AVS2YUV verursachte einen Fehler durch eine ungültige Seite
in Modul KERNEL32.DLL bei 015f:bff7b997.
Register:
EAX=00000000 CS=015f EIP=bff7b997 EFLGS=00000246
EBX=00ad2780 SS=0167 ESP=017afb64 EBP=00ac38c0
ECX=00bd6b20 DS=0167 ESI=6fd30df0 FS=557f
EDX=00ac38c0 ES=0167 EDI=00000004 GS=0000
Bytes bei CS:EIP:
ff 76 04 e8 26 89 ff ff 5e c2 04 00 56 8b 74 24
Stapelwerte:
00bc0490 6fb169b2 6fd30df0 00ad2780 00bc0490 6fb26e5d 00ad2780 557f0167 00000000 6fac2e38 00ac38c0 bff9ab2b bff7b30e 00000000 00bc0490 00000004

[CruNcher]

akupenguin how far is b-frame decoding in libavcodec for H.264 by now ?
i get damaged output with the newest videolan vlc-0.8.0-win32-20041101
i used Weighted Prediction, B-frames and Cabac in this clip

http://cruncher.mufflastig.com/h264/libavcodec_h264_b-frame-problem.png

[ak]

Originally posted by hellfred
I have downladed that binary from 4nykey's side linked by ak.
These are one person, actually, I just use either of these nicks, when another is taken by someone else.

As for avs2yuv not being win32 binary, probably site's fault. 'Save as' most probably won't work, left click should do.

Regarding crash, no idea, it runs (and exits) smoothly on win2003, haven't tried it on any other machine.

[akupenguin]

Originally posted by CruNcher
akupenguin how far is b-frame decoding in libavcodec for H.264 by now ? Weighted prediction is not supported at all. (That probably caused the discolored blocks, but can't be related to the streaks.) CABAC should pose no problems. The only known issue with B-frames is that they are displayed out of order. But I'm open to any video clips that break decoding, if you want to send it to me.

[hellfred]

Originally posted by ak
These are one person, actually, I just use either of these nicks, when another is taken by someone else.

As for avs2yuv not being win32 binary, probably site's fault. 'Save as' most probably won't work, left click should do.

Regarding crash, no idea, it runs (and exits) smoothly on win2003, haven't tried it on any other machine.
avs2yuv does not work well on WinXP SP1, too. It is even worse. My testing script was just an
AVISource("C:\FUll\path\to\file.avi")
with three different avis containing MPEG4 encodes.
I could always open it in VDubMod easily, and in my DShow Player BSPlayer. But only the smallest (in terms of both resolution and file size) could be streamed to mplayer, giving me a error message ahead of mplayer displaying the video. Video playback started after clicking away the error message.
Is that due to the fact that i did not eleminate the audio track?

Hellfred

[akupenguin]

Originally posted by hellfred
Is that due to the fact that i did not eleminate the audio track?
avs2yuv completely ignores the audio track. that shouldn't be an issue.

[hellfred]

Originally posted by pogo stick
After installing Helix YV12 / I420 VFW codecs avs2yuv started to work without problems (no green video)...
Can you point me to a location where i can find this codec, please? Finding anything on helixcommunity.org is impossible, and google did not help either. Up to now i have tryed xvid and ffdshow for decode, but both are unstable. I know that once one programm that i installed came with it (RealAnime?) but i can not find it no more.
Hellfred

EDIT:
Found it here (http://forum.doom9.org/showthread.php?s=&threadid=56972) in the forum.

[hellfred]

Finally everything is next to working smooth with the latest build of avs2yuv on WinXP and Win98, as long as i only decode 500 frames (-frames 500). The first binary that I have downloaded from ak got truncated somewhere in the download process. Getting another one fixed that.
Then output was unstable on Win98 when decoding using XviD v1.1 alpha build, and failed using ffdshow configured for processing raw videos, but with helix vfw codec finally i get some frames. Although there is still a error message to click away, so that using avs2yuv in batchs/scripts is still impossible, as nobody is there to click away the error message e.g between two passes of a multipass encode or differnt encodes. :(
On WinXP I had to get rid of DivX v5.0.2, as the output was all green, and install Helix vfw codec. But again an error message makes it impossible to do unattained batch encodes. :(

On Win98 i get the error message mainly at the end of decoding:

AVS2YUV verursachte einen Fehler durch eine ungültige Seite
in Modul KERNEL32.DLL bei 015f:bff7b997.
Register:
EAX=00000000 CS=015f EIP=bff7b997 EFLGS=00000246
EBX=00b85e40 SS=0167 ESP=016efb64 EBP=00ac4dc0
ECX=00bd6ba0 DS=0167 ESI=6fd30df0 FS=52bf
EDX=00ac4dc0 ES=0167 EDI=00000004 GS=0000
Bytes bei CS:EIP:
ff 76 04 e8 26 89 ff ff 5e c2 04 00 56 8b 74 24
Stapelwerte:
00ac488c 6fae4e52 6fd30df0 00b85e40 00ac488c 6fb26e78 00b85e40 52bf0167 00000000 6fac2e38 00ac4dc0 bff9ab2b bff7b30e 00000000 00ac488c 00000004

No matter if i tage the msys, cygwin or ReactOS cmd.exe console.

Just usingure, build in command.com i get it ahead of mplayer showing the video. Command.com is a little bit faster than the other three consoles.

AVS2YUV verursachte einen Fehler durch eine ungültige Seite
in Modul KERNEL32.DLL bei 015f:bff7b997.
Register:
EAX=00000000 CS=015f EIP=bff7b997 EFLGS=00000246
EBX=00b85e40 SS=0167 ESP=016efb64 EBP=00ac4dc0
ECX=00bd6ba0 DS=0167 ESI=6fd30df0 FS=4437
EDX=00ac4dc0 ES=0167 EDI=00000004 GS=0000
Bytes bei CS:EIP:
ff 76 04 e8 26 89 ff ff 5e c2 04 00 56 8b 74 24
Stapelwerte:
00ac488c 6fae4e52 6fd30df0 00b85e40 00ac488c 6fb26e78 00b85e40 44370167 00000000 6fac2e38 00ac4dc0 bff9ab2b bff7b30e 00000000 00ac488c 00000004

Why a restriction of 500 frames? When i start piping, my Windows partition beginns getting filled rapidly, till after some 200MBs there is not enough space left and mplayer suddenly stops the playback. The Prompt reappears in the console in a new line.
I was wrong about the last one. It is like this:
First: I start the command
avs2yuv test.avs - | mplayer.exe -
Then and i hear that a lot of data is written to the harddrive, till c:\ has not a single byte of freee space left. This takes some seconds. Now I get the error message (probably writing to disk failed to to the lack of free space), click it away, and mplayer starts the playback of the frames that where decoded up untill the computer ran out of free space.
That is not what a pipe is supposed to do :mad:

This behavour is confirmed by the output of avs2yuv just ahead of / just after the error message popps up:
D:\Stefan\msys\1.0\opt\mplayer_x264\bin>avs2yuv.exe test.avs - | mplayer.exe -
test.avs
total frames: 10759
Output error: wrote only 213734 of 230400 bytes
The data are being writen to a file named "AJCKACDC" (command.com) or "CMDF001.TMP" (ReactOS cmd.exe) residing in c:\Windows\temp.
Any idea hot to fix this? Is there any information that i can provide for you to understand this bug? Or is there no way to implement something like a "real" pipe in Win9x that handles the information from one process to the other "on the fly"?

Hellfred

EDIT: Cygwin bash is somehow able to pipe the output without writing the data to disk ahead. Looks like the cygwin1.dll takes care of the simulation of the linux/unix kernel/OS quite well, but i have to pay for this with a heavy impact on performance. Like only half the frames are decoded and served per time unit.
And there still remains the problem of an error message at the end of decoding:
[code]AVS2YUV verursachte einen Fehler durch eine ungültige Seite
in Modul KERNEL32.DLL bei 015f:bff7b997.
Register:
EAX=00000000 CS=015f EIP=bff7b997 EFLGS=00000246
EBX=00b85e40 SS=0167 ESP=017afb64 EBP=00ac4dc0
ECX=00bd6ba0 DS=0167 ESI=6fd30df0 FS=4fb7
EDX=00ac4dc0 ES=0167 EDI=00000004 GS=0000
Bytes bei CS:EIP:
ff 76 04 e8 26 89 ff ff 5e c2 04 00 56 8b 74 24
Stapelwerte:
00ac488c 6fae4e52 6fd30df0 00b85e40 00ac488c 6fb26e78 00b85e40 4fb70167 00000000 6fac2e38 00ac4dc0 bff9ab2b bff7b30e 00000000 00ac488c 00000004[\code]

[Leak]

Originally posted by hellfred
Why a restriction of 500 frames? When i start piping, my Windows partition beginns getting filled rapidly, till after some 200MBs there is not enough space left and mplayer suddenly stops the playback. The Prompt reappears in the console in a new line.
I was wrong about the last one. It is like this:
First: I start the command
avs2yuv test.avs - | mplayer.exe -
Then and i hear that a lot of data is written to the harddrive, till c:\ has not a single byte of freee space left. This takes some seconds. Now I get the error message (probably writing to disk failed to to the lack of free space), click it away, and mplayer starts the playback of the frames that where decoded up untill the computer ran out of free space.
That is not what a pipe is supposed to do :mad:

Ah, but that's the way piping was/is implemented in DOS and Win9x/ME command interpreters - writing the output of one program to a temp file and feeding that to the next one in the pipe. You can't do anything about it, other than either upgrading to a newer windows or use a different shell, like Cygwin bash or zsh.

Cygwin bash is somehow able to pipe the output without writing the data to disk ahead. Looks like the cygwin1.dll takes care of the simulation of the linux/unix kernel/OS quite well, but i have to pay for this with a heavy impact on performance. Like only half the frames are decoded and served per time unit.

Of course - after all, both the encoder and decoder are now running at the same time, whereas before the decoder's output was dumped to a file which was read in again afterwards...

[hellfred]

Sorry for highjacking the x264 development thread
I have start a new thread (http://forum.doom9.org/showthread.php?s=&threadid=84852) in the AviSynth usage section of this forum. I wellcome akapenguin, ak and all the others to discuss avs2yuv usage and to help getting it working under win32 there.

Hellfred

[Tommy Carrot]

Apparently the underquantization bug in fixed quantizer mode has been fixed in ffdshow, it works flawlessly in Celtic_druid's latest build.

[celtic_druid]

http://celticdruid.no-ip.com/test/ ff_x264.2004.10.30 ones are the same was in my recent ffdshow builds, but with -march/mtune=Athlon-xp/pentium4. I guess that (ff_x264.dll) is what solved the problem so it should also work with the latest sourceforge builds.

[hellfred]

Here is a small feature request.
Is it possible to add a switch that will disable the output of the video frames? When doing a multi pass encode, the logfile is all what is needed to run the next pass. Discarding the frames can help when one has only limited disc space. This is done by several other codecs / encoders, too, e.g. Xvid and ffdshow.

Hellfrd

[akupenguin]

That feature doesn't belong in x264: it's not codec specific, and doesn't save any encode time (at least not unless I optimize CABAC for the case where we only care how many bits it would output.) Ask ffdshow to extend their discard 1st pass option to all codecs.

[hellfred]

In ffdshow one just has to uncheck "Store frames to AVI", and nothing is written to a file, no matter which codec you have chosen for encoding.
Actually the basic idea was to keep mencoder from writing the first pass to harddisk. On Linux one can use -o /dev/null and on win32 -o NUL: as a workaround. I have learned the later one from Leak after i have asked this question here.
So please spend your time on improving this great codec of yours. And thank you for the great work up to now.

Hellfred

[virus]

Here's what I got in the last days when trying to update or checkout the sources for x264 using SVN. It worked until a week or two ago.

$ svn co svn://svn.videolan.org/x264/trunk x264
svn: Berkeley DB error while opening 'nodes' table for filesystem /var/lib/svn/x264/db:
Cannot allocate memory

Same output for "svn status" or "svn update".
I've tried with some permutations of the above cmdline (x264-trunk and similar, following the hints on videolan.org) but I always get the same error. I've also tried a fresh checkout of the VLC sources from the same server and everything worked perfectly. What happened?

[Sirber]

yep, same here:

sirber@detrinux sirber $ svn co svn://svn.videolan.org/x264/trunk x264
svn: Berkeley DB error while opening 'nodes' table for filesystem /var/lib/svn/x264/db:
Cannot allocate memory

[hellfred]

Don't mind it being broken, as there are only very few modivications to the source code that can be tracked through the development mailing list via this link (http://www.via.ecp.fr/via/ml/x264-devel/).
Siber, don't you have a Athlon64. Have a look at the last mail of oktober (http://www.via.ecp.fr/via/ml/x264-devel/200410/msg00033.html) .

Hellfred

[Sirber]

No

Brand old AMD XP 2000+ :o

[Sagittaire]

Preview: very good test for x264

http://jfl1974.free.fr/Test/Comparatif/PSNRAverage.gif

http://jfl1974.free.fr/Test/Comparatif/PSNROverall.gif

[gotaserena]

I just tested revision 59 on two different encodes. The first went fine (TV capture, noisy), but the DVD backup I was making with bitrate set to double what qp_constant=22 said seg faulted with this error:

x264 [error]: Error: 2pass curve failed to converge
x264_encoder_open failed.

If I reduce the bitrate it encodes fine.

Anybody found some similar behaviour?

[akupenguin]

Try r60. It won't fix the error, but it will provide more information on what happened.

[gotaserena]

I'm recompiling mplayer and will begin encoding soon.

I'm also having these problems with some frames:

http://img120.exs.cx/img120/5152/sample-problem.th.png (http://img120.exs.cx/my.php?loc=img120&image=sample-problem.png)

qp_min=15:qp_max=45:nofullinter:cabac:keyint=250:subq=2
deblock:deblockalpha=2:frameref=5

[akupenguin]

To help with that I would need not just a snapshot, but a source clip and compressed clip that demonstrate the problem (preferable short clips. and the source need not be lossless, as long as it's what you actually gave to mencoder), along with the exact encoder command line.

[gotaserena]

Here's it aku (ankka?)

Source (http://s5.yousendit.com/d.aspx?id=2DD4C707B54AA8FE857CCF0B9A97EF82)

1-pass:
mencoder -mc 0 -noskip -skiplimit 0 -nosound -o /dev/null -vf scale=384:288 -ovc x264 -x264encopts pass=1:qp_constant=22:nofullinter:cabac:keyint=250:subq=2:deblock:deblockalpha=2:frameref=5 -of avi segment-day01.mpg

2-pass:
mencoder -mc 0 -noskip -skiplimit 0 -nosound -o segment-avc.avi -vf scale=384:288 -ovc x264 -x264encopts pass=2:bitrate=1168:qp_min=15:qp_max=45:nofullinter:cabac:keyint=250:subq=2:deblock:deblockalpha=2:frameref=5 -of avi segment-day01.mpg

Result (http://s5.yousendit.com/d.aspx?id=7AF861860CBE9528F8E0FA275357FEC2)

BTW, thanks for the revision. I saw that I foolishly had set qp_min too high to manage the bitrate I wanted. Still it's better to have a reminder than a core dump :D

[akupenguin]

I confirm the error, and notice that all the extraneous black rectangles are Skip macroblocks. Skip simply copies the block from the previous frame, and the motion vectors look reasonable. This leads me to believe that it's a bug in lavc's decoder rather than in x264.
But I'm happy to patch lavc too, so I'll see what I can do.

Sidenote: you'll get improved quality by using "-vf field=0,crop=684:284:12:2,hqdn3d=5,scale=368:288": As long as you're downscaling interlaced content, you keep more detail by dropping one field rather than blending them. And black borders are also bad.
(Your error happens to go away when I add the crop filter. Maybe lavc is erroneously replicating pixels from the edge of the frame?)

p.s.
Here's it aku (ankka?)aku:
悪 【あく】 (n) evil; wickedness;
悪戯 【いたずら(P); あくぎ】 (adj-na,n,vs) tease; prank; trick; practical joke; mischief
(no relation to either the magazine Aku Ankka nor Donald Duck.)

[gotaserena]

Hmm, sorry for not trying to decode the file in windows before complaining here. At least something was learnt. Thanks for all the help and sorry for the bad joke!

[akupenguin]

What codec would you use under windows? ffdshow uses lavc too, so it should have the same bugs. Unless you have a beta of Ateme?
Anyway, you did uncover a bug, and I will try to fix it.

[gotaserena]

Ok, I did some encodes in windows (using celtic_druid's builds, based on r59 I believe).

The problem does not show in pass=1, decoding with libavcodec.

The problem does show in pass=2, decoding with libavcodec.

I thought it would be a simple thing to decode the output using Moonlight's H.264 decoder, but alas no luck, no matter what container I used. Funnily mp4creator refused to put the stream into mp4.

To add to the confusion, I found out that "AVI Decompressor" (aka M$'s quartz.dll) could decompress the source, albeit upside down. The blocks were still there.

[RadicalEd]

Originally posted by gotaserena
To add to the confusion, I found out that "AVI Decompressor" (aka M$'s quartz.dll) could decompress the source, albeit upside down. The blocks were still there.

That's just ffdshow's vfw part.

[gotaserena]

So, is quartz.dll some sort of DShow wrapper for vfw codecs?

[akupenguin]

Originally posted by gotaserena
The problem does not show in pass=1, decoding with libavcodec.
The problem does show in pass=2, decoding with libavcodec. Are you sure that's not just a question of quantizer? Try a first pass with different qp_constants.

[gotaserena]

Yes that seems a problem of quantising...
@q=22 there's no problem
@q=25 it begins to show and gets worse as q raises.

This is surely consistent with your point that these are regions the codec chooses not to change from one frame to the other. As q increases, so does the region in the approximation taken.

I compiled the reference codec from the link you posted elsewhere but I must admit my knowledge on how to deal with raw yuv files is wanting. If I could play the stream I could tell for sure if this is the decoder's fault.

[gotaserena]

Ok, here's what I did to avoid (unsucessfully) using libavcodec -- in windows -- during this game.

- Open the MPEG2 source in VirtualDubMod, resized to 512x384 using the built-in Lanczos filter and saved in huffyuv. Now since in all probability vdm uses libavcodec to decode mpeg2 I was left with little choice than just open the resulting video to see whether the problem showed up. It did not. By the way ffplay ran the huffyuv file without any black boxes either.

- mencoder -mc 0 -noskip -skiplimit 0 -nosound -o segment-q30.avi -ovc x264 -x264encopts pass=1:qp_constant=30:nofullinter:cabac:keyint=250:psnr:subq=2:deblock:deblockalpha=2:frameref=5 -of avi segment-hfyu.avi
Here's another point where I depend on libavcodec, but since ffplay did not show any black boxes, I went on and trusted that this step did not screw things up.

- Resulting file shows boxes on frames 40, 111 and 173 when played using a libavcodec decoder.

- avi2raw60 segment-q30.avi segment-q30.264 (avi2raw60 from mpeg4ip (http://mpeg4ip.sourceforge.net/))

- Compiled the source from http://iphome.hhi.de/suehring/tml/download/ and decoded the file segment-q30.264 using ldecod.exe. The input parameters for the decoder where kept on default.

- Converted from YUV 4:2:0 to RGB24 using this (http://www.ee.surrey.ac.uk/Personal/S.Worrall/dloads/yuv2avi_p2.zip) utility. The program wraps the resulting stream in avi so I can open it using virtualdub.

- The final file shows boxes on frames 40, 111 and 173.

[RadicalEd]

IIRC VDM uses libmpeg2.

[akupenguin]

OK, I enabled the debug output of decoded frames, and x264 itself displays the blocks. New hypothesis: the skip decision algorithm is too lenient at high quants. (I already know it's too strict at low quants.)

edit: yep, that's it.
Conditions for the bug: If the current area of the picture is flat (no gradient or detail), and the motion vector predicted from the neighboring blocks points to a flat region of another color (in this case black), and the inter DC quantizer brings that difference down to 1 unit, then the block will be erroneously skipped.
Now, how to fix it without killing the whole pskip decision? I might need more psychovisuals than just the current hadamard + weighted coeffs.
Eventually I'll implement a rate/distortion optimal skip decision, but there must be some fast way, too.

[pogo stick]

Maybe it's too early for this and there are some other more important stuff that can be improved and implemented, but I just thought about this feature. Will it be hard to do in encoder? Is it similar to MPEG-4 video - PAR in bitstream? And I wonder if FFDShow already capable of auto-resizing anamorphic H.264 video?

[gotaserena]

My H.264 encodes always play with the correct aspect ratio (using ffdshow). I'm not sure whether the line
ODML: vprp aspect is 16384:6387
that mencoders shows when closing the video file is an AVI header or MPEG-4 bitstream but the aspect ratio is right whether the video is in .avi or .mp4, and in the latter case I extract the bitstream from the avi container before muxing.

[akupenguin]

Fixed.
x264 already supported PAR, but MEncoder didn't set that parameter.

[giandrea]

Originally posted by gotaserena
My H.264 encodes always play with the correct aspect ratio (using ffdshow). I'm not sure whether the line
ODML: vprp aspect is 16384:6387
that mencoders shows when closing the video file is an AVI header or MPEG-4 bitstream but the aspect ratio is right whether the video is in .avi or .mp4, and in the latter case I extract the bitstream from the avi container before muxing.

Hi gotaserena! How do you mux h.264 video into MP4? Do you use the latest mpeg4creator from CVS? I tryed to compile it, but it failed under MacOS X, I will try again soon anyway.

[pogo stick]

Look here (http://forum.doom9.org/showthread.php?threadid=84456).

[giandrea]

Talking about quality, from a test that I've done recently, x264 at fixed quantizer=19 and 1Mbps scored an average psnr of 52.75, while xvid scored an average psnr of 52 at 2.3 Mbps for the same clip. Is it possible for x264 to be so much superior to xvid in the early developement stage it is in now? Or I made some mistake and x264 hasn't got that high psnr?
thanks,

giandrea

[Mug Funky]

either:

a) x264 is really kicking a$$
b) you scored some choice x264 settings
c) you broke xvid's settings :)

hehe... maybe it's all 3. but x264 is looking very promising, at any rate. i get the impression that right now it's not even close to what it could finish up as. that fills me with optimism, as it's already awesome.

[snacky]

Just guessing, but I'll vote for:

d) neither encoder achieved the requested bitrate, so the comparison turns out to be invalid ;)

There are certain sequences that may be encoded at low cost with h.264, but are "pathological" for mpeg4 asp. I've been known to perseverate on certain types of rapid flashing sequences, where you can get nearly arbitrary (e.g., 1/100th the bitrate) improvements with h.264 as compared to mpeg4 asp.

But in my experience, you're very lucky to see x264 get more than a 25-30% bitrate improvement over xvid or lavc, and the more typical case is only a marginal improvement.

[Tommy Carrot]

In my experience x264 has big advantage at low bitrates, where the image of xvid tends to fall apart, while x264 remains solid. But at higher bitrates, the advantage is not clear, or there are cases where x264 is even inferior to xvid. This can be attributed to inloop-filtering imo, which can smooth away the finer details even at higher bitrates, thus making the video looking "flat". Disabling or weakening the loop-filter is not a real solution to this, because the blocking in h.264 (at least in current implementations) is much more distracting and annoying than in advanced simple profile.

[akupenguin]

Originally posted by Tommy Carrot
Disabling or weakening the loop-filter is not a real solution to this, because the blocking in h.264 (at least in current implementations) is much more distracting and annoying than in advanced simple profile. Hopefully that will be addressed by H.264 high profile, which allows a transform more like ASP's DCT. No word on when I'll have time to implement it, though.

[virus]

Hi,

seeing that the commandline encoder seems to have been updated recently, I decided to give it a shot. So I fed it with the simple cmdline:
x264 -o test.h264 foreman.yuv 352x288


and ended up with something like this in the output (I've replaced the ridiculously long overflowed numbers with the short "huge value" text...):

...
x264 [info]: analyse=76(2760ms) encode=0(10ms) write=380(0ms) filter=10(370ms)
x264 [info]: slice I:1 Avg QP:23.00 Avg size:13629 PSNR Mean Y: (huge value)
U: (huge value) V: (huge value) Global: (huge value) MSE*Size: (huge value)
x264 [info]: slice P:29 Avg QP:26.00 Avg size:2372 PSNR Mean Y:-0.00
U: 0.00 V: 0.00 Avg: (huge value) Global: (huge value) MSE*Size: (huge value)
x264 [info]: slice I Avg I4x4:319 I16x16:0
...

Houston we have a problem :)

Also, I'd like to know if there's a way to retain the "x264 [info]" output without the lengthy per-frame info labelled "x264 [debug]"; the option "--quiet" removes almost everything from the output. I don't see a "log level" option in the encoder (but I think there was one available in x264, or not?).

virus

[akupenguin]

I reduced default verbosity to [info], and added a -v to put to back to [debug].

The messed up stats are probably a failure to recompile something after updating. I've never got annoyed enough at make to track down the problem, since jam works.

[virus]

hey, that was quick :)

Thanks. As for the messed up stats, yeah, sometimes things gets screwed due to missing dependencies in the makefile, but not this time it seems: I've checked out a completely fresh copy of revision 81 and compiled it: the error is still present.

[akupenguin]

Works For Me (tm).

[virus]

No problem, I've already tracked the issue... this is the Week Of Programs That Break On My Machine Only. :D

It's the usual incompatibility introduced by Micro$oft in their msvcrt.dll implementation. Instead of using the ISO standard "%lld" prefix for 64-bit integers, they use their own "%I64"-based format. I use MinGW and it of course is forced to behave the same way to produce code that work on M$'s runtime libraries.

So, I changed line 1354 of /encoder/encoder.c to:
"slice %s:%-4d Avg QP:%5.2f Avg size:%-5I64u PSNR Mean Y:%5.2f U:%5.2f V:%5.2f Avg:%5.2f
Global:%5.2f MSE*Size:%5.3f\n",

Note the change in the "Avg size" field. Now the output looks OK, unless you're able to identify further problems that I currently don't see:
x264 [info]: slice I:1 Avg QP:23.00 Avg size:13629 PSNR Mean Y:41.08 U:44.10 V:46.82
Avg:42.08 Global:42.08 MSE*Size:0.844
x264 [info]: slice P:29 Avg QP:26.00 Avg size:2680 PSNR Mean Y:37.78 U:41.72 V:44.64
Avg:38.93 Global:38.91 MSE*Size:0.345

I'm not sure what kind of defined symbol we need to test to fork between the 2 versions of the code, though. Any idea?

virus

[akupenguin]

Interesting. I see several cases of %lld in MPlayer, and the official win32 builds use MinGW, and I haven't heard of this issue from there...

If this really is the problem, the easiest fix is to cast most of them back to int and use "%.0f" for the rest.

[virus]

Well, it's quite possible that newer versions of Windows come with a more decent version of msvcrt.dll that supports the ISO format strings... but I have Win98SE here, and I guess nobody tests against it. You should just see the spectacular bluescreens that Videolan produces here when you try to play something ;)

Anyway, this is the note I have in /MinGW/include/inttypes.h:

/* 7.8.1 Macros for format specifiers
*
* MS runtime does not yet understand C9x standard "ll"
* length specifier. It appears to treat "ll" as "l".
* The non-standard I64 length specifier causes warning in GCC,
* but understood by MS runtime functions.
*/

It's MinGW 3.1.0, not exactly the very latest version but still a recent one.

virus

[virus]

Yet another boring feature request :)

Can we have an alternative makefile added to the repository (named, say, "Makefile.nodebug" or "Makefile.release") without the -g option enabled in CFLAGS and with -s turned on? That gives much smaller filesizes for everything (up to 2.5x smaller)... it would be really handy imho.

virus

[Yong]

1. 4x4 B frame search will be possible in the future?
2. How many options will be available in the complete of x264 encoder?
3. It is possible adding adaptive quantization to x264 encoder?

(sorry for my crappy english and stupid questions):p
Thanks for the replies.:)
too bad, seems noone could answer my questions:devil:

[IgorC]

How can I tune Aspect Ratio for x264 (like in nero avc)?
is it possible to introduce it to bitstream?

[bond]

Originally posted by IgorC
How can I tune Aspect Ratio for x264 (like in nero avc)?
is it possible to introduce it to beatstream? http://forum.doom9.org/showthread.php?s=&threadid=86870

[Sergejack]

Is x264 limited when used in avi container ?

What are the best free and not free containers to use with x264 ?

[bond]

Originally posted by Sergejack
Is x264 limited when used in avi container ?depends
when encoding with sex264 in virtualdub you will loose a specific number of frames in the output depending on the used number of b-frames
b-frames is the only avc technology used till now in x264 causing problems with avi and vfw

apart from that .avi will limit the possible audio/subtitle formats

What are the best free and not free containers to use with x264 ?there is no best, it all depends on what you want to do
but i think x264 is atm already usable in .avi, .mkv, .ogm and .mp4, all of which are free (meaning licensefree and free tools are available for creation and playback)

[len0x]

Originally posted by bond
when encoding with sex264 in virtualdub you will loose a specific number of frames in the output depending on the used number of b-frames


This is worrying. Is there a detail explanation of why and when frames are lost?

[bond]

Originally posted by len0x
This is worrying. Is there a detail explanation of why and when frames are lost? its not really a problem (who cares about 2 of 200000 frames in a movie?)
its just the same old problem that vfw is simply not able to handle b-frames. there are workarounds for this for divx5 and xvid (but for not other codec) in virtualdub(mod) (but in no other vfw based encoding tool), its just that these workarounds are not that easily applyable for x264

also to show the importance of this problem: note that till the last update virtualdub 1.6 was buggy and didnt apply the b-frames fix when encoding with xvid and divx5 for some months, but noone realized it ;)

[Sergejack]

I'm soewhat totally confused.

If I mux an x264 avi file in a mp4 file, will the b-frame trouble be fixed, or is the information lost to start with ?

[bond]

Originally posted by Sergejack
If I mux an x264 avi file in a mp4 file, will the b-frame trouble be fixed, or is the information lost to start with ?the frames are lost "forever" if you use both together:
- sex264 in virtualdub(mod)
- b-frames

if you encode in mencoder with x264 the frames are not lost

[len0x]

Originally posted by bond
its not really a problem (who cares about 2 of 200000 frames in a movie?)


ah, you never said it was just two frames :)

[bond]

Originally posted by len0x
ah, you never said it was just two frames :) well i wrote "2 out of 200000" ;)

actually it depends on how many b-frames you use:
with 1 b-frame in a row you loose 1 frame, with 2 b-frames in a row you loose 2, aso...

[len0x]

Has anyone noticed this: when opening x264 encode (in AVI) in VDubMod via DirectShowSource and scrolling frame-by frame through it - every 5-10 frames you get out of order frame (i.e. a frame that was 2-3 frames back already) then it resumes normally (but frame that was supposed to be instead of dupe is lost though). However normal playback doesn't seem to have this issue.

p.s. ffdshow was used for decoding.

[Bogalvator]

What date is your ffdshow? Try again with the latest celtic_druid compile as it may have been an issue that has been fixed ;)

[len0x]

Indeed, I tried the build from 17th of Jan and its seems ok.

@bond

I made a test and I see no difference in frames between XviD and x264 in AVI (both with 1 b-frame).

[bond]

Originally posted by len0x
I made a test and I see no difference in frames between XviD and x264 in AVI (both with 1 b-frame)during playback you will not see it
also virtualdub will show the correct framenumber, thats because the missing frames are "zero length frames", frames that are marked like frames in .avi, but actually dont exist :D

if you extract the stream from .avi with mpeg4ips avi2raw you will see that it will report 1 zero length frame
also when you analyse the stream with mplayers analysing function you will see the same result

[Sergejack]

A question about the variability parameter :

Is it the variability of the bitrate ? In wich case set it to 100% should be a good thing assuming the RDO function is properly done.

Or is it variability of PSNR (or wathever metric measure the quality) ? In wich case, what should be tough of when setting this parameter ?

[akupenguin]

100% variability is equivalent to constant quantizer. 0% variability is CBR.
There are two factors stopping 100% from being the optimal setting: The human visual system (or at least mine) is less sensitive to errors in high-motion scenes. And the quality of one frame influences the quality of the following frames predicted from it. Neither of those can be determined by any normal RDO algorithm. I have found the PSNR-optimal setting to be around 70%, and the psy-optimal setting to be around 60%. But neither of those have been tested on enough full length movies to be really certain, so YMMV.

[len0x]

Question: how can IDR settings affect compressibility result when using snips of original source? Usually we have 14-frame snips so every 14 frames for XviD/DivX its guaranteed to be an I-frame (that was usually discarded from calcualtions along with last frame of the snip). Now I see that min IDR-keyframe interval is 25. Does this mean that you should no longer discard start/end frame of the snip or discard even more or change snip size to at least 25 to make sure I-frames are inserted only at the beginning of a snip?

Is this also dependent on max frames reference parameter?

[akupenguin]

What are "snips"?
What calculations are you discarding I-frames from, and why?

Note that min keyint does not prevent I-frames from occurring wherever they are appropriate, and increasing min keyint will never reduce compression, only seeking precision. (as long as there's plenty of space between min and max.)
Currently, min keyint only helps with multiple reference frames.

[Manao]

When computing the compressibility, GK uses an avisynth script, selecting 15 consecutive frames every 300 frames. Hence a tendency to put I frames every 15 frames, which makes them overnumerous, so their size must not be taken into account for the compressibility value.

[akupenguin]

For that purpose, you don't need to adjust snip size or calculations, and it doesn't matter what you set min keyint to. min keyint = 14 might be slightly faster.

[len0x]

Actaully everything matters. Let me explain: for compressibility test there are good frames (that contribute to more precise result) and bad frames (that contribute to less precise result). Basically the diffence is how close size of the frame during comp test to what would have been during actual encode. That's why I-frames in the beginning of snip are bad, because they are artificial (i.e. they would usually not be present in the actual encode).

Now, you were saying that min keyframe interval doesn't affect comp test. I was thinking that indeed keyframes are not inserted much more often than usual (if you have much lower snip size than min keyframe distance), however since every non I frame is a difference frame and snips are taken from different parts of the movie then there is bound to be a huge difference between last frame of one snip and first frame of next snip. Situation complicates even more if you have multiple reference frames (if I'm not mistaken ASP only can have one while AVC can have several, right?), because then not only first, but may be more starting frames will be dependent on frames from previous snip (situation that we try to avoid since it won't happen in the actual encode).

So in the end the most logical step would be to have snip_size=min_keyframe_diff. This will ensure that first frame of each snip will most probably be a keyframe, which you can ignore during calculations. I've done some tests and indeed it works! However the most presize result I get is when I don't discard any frames from the snip... (but this may be just a coincidence and source dependent).

P.S. this was all done without trying to use b-frames. It will get really crazy later on when they are taking into account :)

[akupenguin]

First understand that in H.264 there is a distinction between I-frames and keyframes. min_keyint does not control placement of I-frames, it only controls which I-frames are turned into keyframes. The first frame of a snip will always be an I-frame, just like in ASP, no matter what you set min_keyint to. If it is also a keyframe, then the previous snip is unavailable for prediction (which is just fine, because it wouldn't help). If the I-frame is not a keyframe, then the following P-frames could depend on older frames, but they will choose not to, and the result will be the same as in the case of a keyframe.
(The reason I don't just make all I-frames into keyframes is that in a full encode, the frames after a scenecut are not necessarily unrelated to the previous frames: if it cuts and then cuts back to the first scene, you save some bits by putting only non-key I-frames inbetween.)

It is true that you won't see the full benefit of multiple references on the first few frames of a snip, but even with lots of references it's probably not worthwhile to discard more than the first 2 P-frames.

Yes, B-frames make it even more complicated: You definitely want to discard the first set of B-frames in a snip (because they were predicted based from the I-frame, which isn't representative of P-frame quality), and the last set (which is trucated due to closed GOP requirements).

With those points in mind, a snip size bigger than 15 is probably useful. But I can't suggest a new size without lots of tests. Personally, I just use 3-pass encoding, and then I know that the first pass is accurate, and get slightly better ratecontrol too. But I understand that some people are more interested in speed.

[len0x]

Originally posted by akupenguin
First understand that in H.264 there is a distinction between I-frames and keyframes. min_keyint does not control placement of I-frames, it only controls which I-frames are turned into keyframes. The first frame of a snip will always be an I-frame, just like in ASP, no matter what you set min_keyint to. If it is also a keyframe, then the previous snip is unavailable for prediction (which is just fine, because it wouldn't help). If the I-frame is not a keyframe, then the following P-frames could depend on older frames, but they will choose not to, and the result will be the same as in the case of a keyframe.


Thanks, good to know! Now I understand why it is imperative to make comp test with the snip size that equals min keyframe distance(and may be actual I-frames do not matter that much as all my tests so far were more precise when i didn't discard anything)

Originally posted by akupenguin
Yes, B-frames make it even more complicated: You definitely want to discard the first set of B-frames in a snip (because they were predicted based from the I-frame, which isn't representative of P-frame quality), and the last set (which is trucated due to closed GOP requirements).


For XviD it was found to be better to discard first three and last three frames of a snip. I'll test that against x264 later on.

Originally posted by akupenguin
With those points in mind, a snip size bigger than 15 is probably useful.

Well, statistically the smaller the snip the better accuracy is, because snips cover the whole movie range more smoothly. But yes lots of tests are to be done... So far I found snip=14 without discarding any frames the most presize option when not using b-frames (and yes setting min keyframe interval 14 as well).

[Sergejack]

When MAX-IDR keyframe interval is exceeded, what happen ?
Is the current frame just forced IDR ?


I think the MIN-IDR keyframe interval is weird; IDR should be used as soon as no previous references are used, it could be know after the first pass.


I still don't figure the real purpose of the internal deblocking filter, is it really safe to relly on that ?

[akupenguin]

Originally posted by Sergejack
When MAX-IDR keyframe interval is exceeded, what happen ?
Is the current frame just forced IDR ? Yes, though it rarely gets quite that far: The scene-cut detection threshold increases as it nears max keyframe interval, so it usually finds some not quite so bad match somewhat before the hard max.

I think the MIN-IDR keyframe interval is weird; IDR should be used as soon as no previous references are used, it could be know after the first pass. So many ideas, so little time. Yes, a 2 pass IDR decision is on the todo list.

I still don't figure the real purpose of the internal deblocking filter, is it really safe to relly on that ? Internal deblocking ends up with better quality than postprocessing, because it can use the deblocked version of each frame to predict the next frame. An encode with deblocking will always look better than an encode without, though some people prefer to turn down the deblocking strength somewhat (e.g. -3).

[len0x]

Suggestion: make stats file to be choosable in vfw interface. This will come very handy later on.

[virus]

Originally posted by len0x
Suggestion: make stats file to be choosable in vfw interface. This will come very handy later on.
that's already planned and will be in place soon ;)
(together with the ability of updating it during the 2nd pass, which effectively allows multipass)

[Elias]

When will the ffdshow filter contain an mp4 splitter?

[len0x]

First, VFW registry settings for min and max keyframes are swapped :)

Second, if you set min_keyframes = max_keyframes = N then I would have expected that every N frames I have a keyframe. But this is not respected and key frames are appearing anywere below every N frames.

[Sagittaire]

Originally posted by akupenguin
100% variability is equivalent to constant quantizer. 0% variability is CBR.
There are two factors stopping 100% from being the optimal setting: The human visual system (or at least mine) is less sensitive to errors in high-motion scenes. And the quality of one frame influences the quality of the following frames predicted from it. Neither of those can be determined by any normal RDO algorithm. I have found the PSNR-optimal setting to be around 70%, and the psy-optimal setting to be around 60%. But neither of those have been tested on enough full length movies to be really certain, so YMMV.

yes ... H264 ateme too don't use 100% for RC variability.

IMO for RC-optimal variability the best metric is the Overall PSNR ...

[virus]

Originally posted by len0x
First, VFW registry settings for min and max keyframes are swapped :)
Indeed :)
Thanks for reporting it.

Second, if you set min_keyframes = max_keyframes = N then I would have expected that every N frames I have a keyframe. But this is not respected and key frames are appearing anywere below every N frames.
The intra frames you're seeing are probably I-frames, not IDR-frames. The option only affects IDR-frames.
Also, remember that even if I-frames are not guaranteed to be seekable when using multiple ref. frames, they are likely to be seekable anyway if they happen on a scenechange (usually in that case the frames before the I, even if kept as references, aren't actually used because they have totally different content from the ones after the I).
That means that often you won't be able to "see" a difference between an I and an IDR frame just by watching or seeking to them ;)

[CruNcher]

@Sagittaire

From my tests it seems to High encavc prefers more High Motion then Low Motion were x264 does it much better and then it makes no difference if you boost it with full tools or not it will allways look more bad then x264 in the end. Exactly that's the case i expierience now with a nice Low Motion/High Motion mixed up scene quant is +2 to high in the 2pass mode for the Low Motion part ABR does better on it, but i think you can imagine how it looks on the High Motion :P, but really the funiest thing is i boosted that Scene to the max PSNR wise it's alot higher then the x264 clip but visualy it looks bad no mater if i try normal, good, best or extra it allways stays behind x264 (minimal settings) in visual quality for the low motion part and this part is very long (conversation scene) before high motion gets in, to me it looks like every bit is pumped into the High Motion (the motion is so fast you don't recognize it) i hope babayagas new RC will yield better results with such a case in the future.

[len0x]

Originally posted by virus
That means that often you won't be able to "see" a difference between an I and an IDR frame just by watching or seeking to them ;)

I don't watch them...
VDubMod produces a log file with frame sizes along with information about which frames are key-frames (I don't think its about I-frames, but real key-frames that are going to be written in the seek table at the end of AVI file).

[virus]

Originally posted by len0x
VDubMod produces a log file with frame sizes along with information about which frames are key-frames
I fear VDub(Mod) has no clue about the difference between an I-frame and an IDR-frame... the same applies to players. For example you can see very nasty blocking artifacts in MPC if you seek to an I-frame when previous frames are effectively used as references.

From a practical standpoint an I-frame in H.264 is basically just a P-frame all made up of intra blocks, and should be handled like such.

[len0x]

Originally posted by virus
I fear VDub(Mod) has no clue about the difference between an I-frame and an IDR-frame...

Hm... what about seeking then? I assume that if I set minimum IDR distance I should not be able have seekable frames in between even if scene changes, right? Or you're saying that even if frame is not marked as key-frame by the codec, but writing application (like VDubMod) treats every I-frame as key frame and therefore puts them into container as keyframes anyway?

[virus]

Originally posted by len0x
Or you're saying that even if frame is not marked as key-frame by the codec, but writing application (like VDubMod) treats every I-frame as key frame and therefore puts them into container as keyframes anyway?
^^^^ This is what I'm saying. The application which handles the stream (being the encoding app or a player) needs to be aware that I-frames may not be seekable, and avoid seeking to them (or avoid marking them as keyframes when storing).

Instead I've been able to seek to such frames with MPC (AVI created with VDub) so I guess Vdub simply marks everything as keyframe. I'm not sure if VDub can be "fooled" in some way, making it think that I-frames are P-frames and thus avoiding the problem.

EDIT: looks like the VfW frontend already does the right thing (marks only IDR-frames as keyframes)

[len0x]

that's pretty sad considering lack of development of VDubMod :(

Just curious - how can vfw application get which frames are real key-frames from the codec?

[bond]

wouldnt setting the min IDR interval to 1 lead to that every i-frame becomes an idr-frame?
wouldnt that solve all the problems, but practically not allow reference frames to refer to frames before a scenechange (assuming that every scenechange starts with an i-frame), which practically wont happy often anyways?

Originally posted by akupenguin
(The reason I don't just make all I-frames into keyframes is that in a full encode, the frames after a scenecut are not necessarily unrelated to the previous frames: if it cuts and then cuts back to the first scene, you save some bits by putting only non-key I-frames inbetween.)but this is practically not relevant if you use small reference numbers, like 5, right? because hardly a switch between 2 scenes will take something like 5 frames

[virus]

Originally posted by bond
but this is practically not relevant if you use small reference numbers, like 5, right? because hardly a switch between 2 scenes will take something like 5 frames
AFAIK H.264 allows the use of long-term references - I think that means that the 5 frames are not necessarily the 5 frames before the current one, but they can be drawn from before almost arbitrarily. Of course, the codec must support the feature. (aku please correct me if I'm wrong :))

@len0x:
the codec uses a flag to mark the outcoming frame as keyframe and passes that to VDub; x264vfw already does that for IDR-frames only, apparently - but then I don't understand why you get IDRs closer than keyint_min :confused:

[bond]

Originally posted by virus
AFAIK H.264 allows the use of long-term references - I think that means that the 5 frames are not necessarily the 5 frames before the current one, but they can be drawn from before almost arbitrarily. Of course, the codec must support the feature. (aku please correct me if I'm wrong :))well might be, but practically when i choose 5 reference frames in x264, thats enabling using the 5 frames before the actual ones as reference
and with that, i think, my statement is valid

[len0x]

Originally posted by virus
the codec uses a flag to mark the outcoming frame as keyframe and passes that to VDub; x264vfw already does that for IDR-frames only, apparently - but then I don't understand why you get IDRs closer than keyint_min :confused:

Well, it might be a bug since I get this only when min_keframe = max_keyframe. The behaviour is correct when min_keyframe < max_keyframe (i.e. don't get key_frames closer than min distance).

[len0x]

Where is the revision log published I wonder? (i.e. what was commited)

[Tommy Carrot]

Originally posted by len0x
Where is the revision log published I wonder? (i.e. what was commited)
The changes of the new revisions are posted in the mailing list (here is the archive (http://www.via.ecp.fr/via/ml/x264-devel/) of it, although it lags behind with a few revisions), and you can follow the changes in the SVN too.

[len0x]

Well, I know that list, but it lags behind with 12 revisions now! :)

Is there a web frontend for SVN like for CVS?

[Tommy Carrot]

Originally posted by len0x
Well, I know that list, but it lags behind with 12 revisions now! :) If you subscribe to the list, you'll get the info about the changes immediately.
Is there a web frontend for SVN like for CVS?
http://developers.videolan.org/cgi-bin/viewcvs.cgi/?root=x264

[bond]

Originally posted by len0x
Is there a web frontend for SVN like for CVS? http://developers.videolan.org/cgi-bin/viewcvs.cgi/trunk/?root=x264 :)

[len0x]

Great! 10x

[Sirber]

Gonna put that on my site :D Thanks!

[Sergejack]

Isn"t VFW an outdated technology wich should be avoided ?

BTW : Is Mencoder relaying on another technology ?

[Sirber]

mencoder is not VFW. And yes, VFW is old and smelly, but everything still works with it. I saw some dshow codec, but it's not the same and not well supported.

[len0x]

VFW will be used until DShow version of VDub will be out (if ever). No codec will be popular in masses without VFW interface for the time being (heck look here - h264 was being developed for how long already? - yet only with VFW interface it's starting to kick in).

[len0x]

VFW GUI resets encoding type to constant bitrate no matter what was selected previously (saving works ok as I see correct value in the registry after I close codec settings).

[len0x]

I was looking at the stats file from the first pass and saw this:


in:0 out:0 type:I q:23.000 itex:43433 ptex:0 mv:12597 misc:250 imb:640 pmb:0 smb:0;
...
in:144 out:144 type:i q:23.000 itex:258490 ptex:0 mv:25100 misc:66 imb:640 pmb:0 smb:0;


What's the difference between type "I" and "i" ? :)

[virus]

Originally posted by len0x
VFW GUI resets encoding type to constant bitrate no matter what was selected previously (saving works ok as I see correct value in the registry after I close codec settings).
ehm, I encoded quite a bit with rev. 105 (and other people did as well) and nothing similar ever happened... anyway I recommend to completely uninstall revisions < 105 before installing 105 (or 106, which fixes the 2 swapped entries in the registry) and then immediately hit Load Defaults and OK to save the default settings in the Registry.

Updating by overwriting can lead to strange behaviour in VDub, apparently even if you hit Load Defaults (can't reproduce here, but at least 1 person reported so). The first time you load x264 in VDub weird things may happen and give you errors. So, better uninstall first ;)

[RadicalEd]

I think long term references were only introduced with high profile :O

[akupenguin]

Long term references are part of Baseline, even. They're just hard to use effectively.

[len0x]

Originally posted by virus
ehm, I encoded quite a bit with rev. 105 (and other people did as well) and nothing similar ever happened... anyway I recommend to completely uninstall revisions < 105 before installing 105 (or 106, which fixes the 2 swapped entries in the registry) and then immediately hit Load Defaults and OK to save the default settings in the Registry.


This doesn't help. Apparently some ppl have also some issues here:
http://forum.doom9.org/showthread.php?s=&postid=600067#post600067

My problem is very wierd because what I do in GK is:
- load saved settings from a registry file (if exists)
- launch config window via ICConfigure()
- save registry to a file

So the first time I launch settings (without restoring config) everything is just fine, but second time codec resets itself to CBR mode (although registry settings are correct!). This did not happen with rev 103. It almost looks like x264 fails to read registry because of shared access (tries exclusive access may be and fails because a lock from previous writing is not released yet) or something like that.

P.S. where can I get rev 106? It doesn't seem to be up anywhere...

[708145]

rev 106 is on my mirror.

http://www.iti.uni-stuttgart.de/~bergmats/video_mirror/videotools/

bis besser,
T0B1A5

[celtic_druid]

Should be up here: http://www.aziendeassociate.it/cd.asp?dir=/x264 some time soon and it is already up here: http://www.iti.uni-stuttgart.de/~bergmats/video_mirror/videotools/

The changelog by the way: registry values for min/max keyint were mixed up .

[len0x]

I've tested this VFW GUI reset problem with revisions 103, 105 and 106 and only 103 is correct. Something got defintely messed up in 105 when stats file path was introduced.

[Sharktooth]

106 is up in the main mirror

[CruNcher]

len0x i also have a problem now that i hadn't before sometimes the config window cant be accessed anymore it does not show up very strange, it looks like algern0n messed something up ;)

[virus]

I cannot reproduce that, but I will check the code again ;)

[len0x]

If you need help I can test any binaries as I have 100% reproducibility here :)

[Tommy Carrot]

Quoted from another thread:Originally posted by Sirber
x264 fails on my HDTV test encode at 1280x720. AVS2AVI gives me a nasty exitCode :confused: I've experienced the same with virtualdub. It seems x264 doesn't like a few resolutions, i've got crashes at 1280x720 and 768x576 too.

[Sirber]

ok, thanks. About the quote, I will use this thread instead :o

[niamh]

I can confirm what len0x said, I have the same issues here, with rev 105 (will try rev 106 now)

[Sirber]

How can I compile the source with studio? Last time I tryed I wasn't aboe to open the project file... I know, bouh sirber bouh!!! :devil:

[Sharktooth]

sirber: no need to compile with studio. pre compiled binaries (from Celtic Druid) are available here: http://celticdruid.no-ip.com/xvid/
Now the files are hosted on one of my server and the download speed is very good.

[len0x]

that's not fun :)
Not being able to play with sources - how sad is that? :cool:

[Sharktooth]

ehrrmmm...

[Sirber]

The point is not to get the binaries, it's to play with the source :o Any tutorial? :D

[hellfred]

Originally posted by Sirber
The point is not to get the binaries, it's to play with the source :o Any tutorial? :D
Why mess with MS if you can take MinGW. Just install current MSYS and MinGS, compile nasm and you are ready to take off.
In MSYS shell change into x264/build/cygwin and run make to build the libs and standalone x264.exe. Then go to x264/vfw/build/cygwin and run yet again make, followed by make install to install the x264vfw dll.
Never had problems with this approach :)

Hellfred

[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'.

[snacky]

No, but you can run "svn log" to see the log notes that appear with each revision.

[ChronoReverse]

http://img86.exs.cx/img86/162/pframe0ag.png
http://img86.exs.cx/img86/5433/bframe17nn.png
http://img86.exs.cx/img86/4302/bframe29vs.png
http://img86.exs.cx/img86/7670/bframe30up.png

The flashing blocks that sometimes come with 3 bframes is occuring. Pframe looks fine. Bframe following is blocked. Bframe following that is fine. 3rd bframe is blocked.

C_D's x264 revision 113 build
2-pass encode targetted at 612kbps (I was aiming for 1/5 CDs for 26 minutes to see how x264 would do)
Load Default Settings
No Fast first pass
Max reference frames: 12
Max B-frames: 3
Max IDR-keyframe interval: 240
Min IDR-keyframe interval: 24

640x480 anime DVD source @ 23.97FPS


I'm making encodes with 0-2 bframes to see what happens.

[akupenguin]

As for why it's blocking in some frames but not others: Changing brightness combined with non-adaptive B-frames and no weighted prediction means that some blocks are predicted as a simple average of the two reference frames. The middle B-frame is exactly half-way between the references, so that's correct. The others are not halfway, but they still use the same prediction.
As for why it's blocking at all: dunno, will do more testing.

For this and other reasons, I do not consider multiple B-frames to be usable in x264.

[Mug Funky]

forgive me if this has been asked before (or if it's just a plain annoying question), but is interlace support on the to do list? i have a buttload of DV footage and also lots of field-blended anime.

i realise a lot of people can't stand interlacing (myself included), but it's going to be a legacy thing for quite a few years to come, and deinterlacing is pointless - if you're using high-quality encoders there's no point ditching up to half your information beforehand.

btw, x264 is kicking severe arse. i love what you guys are doing.

[Manao]

Mug Funky : interlacing is a real pain to support in AVC/h264 ( both in encoder and decoder ). And, even if x264 supported the tools that allows better compression with interlaced content, i think you'd still get a better quality by deinterlacing the video, and encode it at the same bitrate ( you lose some motion, but you gain a lot in picture quality after encoding, at least on a progressive display ). Finally, h264 ( and mpeg-4 ) handle relatively well interlaced content, even without the interlacing tools ( you using these tools correctly makes the codec so slow that you don't want to, anyway... )

[akupenguin]

Interlacing is not planned, and patches for interlacing will be accepted only if they do not increase the code complexity of the rest of the codec. (Which at best means pure interlacing only, no PAFF/MBAFF).

Interlacing is inherently ugly (and interlaced displays only make progressive content ugly, they don't make interlaced content any prettier). The only solution is fix the source, not the codec. Anime is always originally progressive; find a better copy. If you captured your own footage in interlaced DV, then the damage is already done, and you'll just have to find a good motion-adaptive 3D deinterlacer (not that I'm saying such a filter exists). IMNSHO, even simply throwing away one field is an improvement over watching interlaced video, let alone compressing it.

Similarly, I don't plan to add interlacing support to libavcodec's H.264. Though it's already partially present, and there are other people working on lavc, so support might appear anyway.

And that's just my reasons for not wanting to touch interlaced video. I haven't even gone into implementation details.

Originally posted by Manao
Finally, h264 ( and mpeg-4 ) handle relatively well interlaced content, even without the interlacing tools
Interlaced content in a non-interlaced codec adds lots of high-frequencies, and makes vertical motion compensation completely impossible.
I just ran a test using current x264, comparing compression of 30p content decimated by either interlacing or by dropping frames. Result: 15i took 1.8x the bitrate of 15p at a given qp, and 2.0x the bitrate at a given psnr. 30p at half height (deinterlaced) took 1.1x the bitrate of 15p.

[gotaserena]

Sorry for the OT, but there's something I've never quite got in this interlacing business:

Suppose the source material is pure interlaced -- like TV captures or smthg similar. What is wrong about the idea of having the codec separate the fields before encoding and having the interlacing done "on the fly" during decoding (assuming you don't want it bobbed or blended or something else)?

[akupenguin]

Originally posted by gotaserena
What is wrong about the idea of having the codec separate the fields before encoding and having the interlacing done "on the fly" during decoding? That's exactly what interlaced H.264 is. (Assuming you're not using PAFF or MBAFF.)

[gotaserena]

I had to look up those words! :) I've read somewhere that XviD's interlaced mode consisted of "not spending too many bits on combing effects" (I'm paraphrasing here), and I assumed that you had the same thing in mind for x264. It would be nice to have this simple algorithm, anyways.

[Yong]

Originally posted by 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...

It seems my question too hard for answer:D
ok, i make it simple:
anyone try to compare video quality 2pass encoding at 400kbps(other bitrate also can);)
with Npass encoding at 400kbps?

[Mug Funky]

I just ran a test using current x264, comparing compression of 30p content decimated by either interlacing or by dropping frames. Result: 15i took 1.8x the bitrate of 15p at a given qp, and 2.0x the bitrate at a given psnr. 30p at half height (deinterlaced) took 1.1x the bitrate of 15p.

those are some interesting numbers. so i'd be better off full-rate deinterlacing and encoding in twice the frame rate? i guess my machine's overdue for an upgrade anyway...

it's just a pity that so much of the footage out there is interlaced. progressive films are actually the exception rather than the rule.

i can live with xvid for now, at least for my interlaced stuff :)

[akupenguin]

Originally posted by gotaserena
I've read somewhere that XviD's interlaced mode consisted of "not spending too many bits on combing effects" (I'm paraphrasing here), and I assumed that you had the same thing in mind for x264. No, ASP has the same ideas of field-based MC and DCT, PAFF, and MBAFF. The only difference is that for the AFF types, ASP just splits and joins fields, while H.264 downscales or deinterlaces as needed, and also scales MVs for temporal prediction.

[Manao]

There's no PAFF in ASP, only a kind of MBAFF ( interlaced DCT and interlaced motion compensation ). XviD only handles interlacing with interlaced DCT, which doesn't help that much ( in comparison to VHQ4 without interlacing )

When I said h264 / mpeg4 handles relatively well interlaced content, it was in comparison to h264 / mpeg4 with PAFF / MBAFF, with roughly the same speed settings.

[708145]

Originally posted by Mug Funky
those are some interesting numbers. so i'd be better off full-rate deinterlacing and encoding in twice the frame rate? i guess my machine's overdue for an upgrade anyway...


It might be a bit OT but:
1) Is there a good smart deinterlacer that produces 60p from 60i content at full resolution? Not just blend field or such!
2) How much more bitrate would x264 consume with 60p compared to 30p (both full resolution). I guess B-frames are _very_ important there.

edit: spelling error fixed.

bis besser,
Tobias

[temporance]

Does there exist a working H.264 VfW decoder anywhere?

Here's what I've already tried:

- x264 : doesn't decode
- VSS decode set: only DShow decoder supplied
- VSS 5-day trial: buggy decode with block artifacts (looks like PP because errors don't propagate). Also looks like B-frames are not reordered.
- FFVFW: haven't been able to get this working yet.

I really need a native VfW decode: can anyone help?

[Sharktooth]

latest ffdshow (that includes ffvfw too).
http://www.aziendeassociate.it/cd.asp?dir=/ffdshow

[Tommy Carrot]

Yes, the latest ffdshow, but you have to enable the h.264 decoding on the VFW codec configuration/decoder/codecs tab, because it's disabled by default.

[Sharktooth]

exactly, you should enable this 4cc in ffvfw configuration (set it to libavcodec):
http://www.aziendeassociate.com/ffdshow-vfw.jpg

result:
http://www.aziendeassociate.com/x264.jpg
Note: the picture image quality does not represent the codec image quality.

[hpn]

Something a little off-topic for this thread, but please use png instead of jpg format (or at least higher quality jpg) when making screenshots, otherwise some people may start thinking that the low quality of the shots they see has something to do with the x264 encoder, which is completely untrue.

[Sharktooth]

well that was not representing the codec quality... ok, i will add a disclaimer...

[Blue_MiSfit]

Akupenguin:
As for why it's blocking in some frames but not others: Changing brightness combined with non-adaptive B-frames and no weighted prediction means that some blocks are predicted as a simple average of the two reference frames. The middle B-frame is exactly half-way between the references, so that's correct. The others are not halfway, but they still use the same prediction.

So, ATM using 1 b-frame is all good, but with more than 1 we might see the evil blocking errors like I was getting with my Family Guy encode awhile back?

Is there any point in having more than 1 reference frame if you are only using 1 b-frame?

Just trying to get things clarified... I am very impressed BTW, this is developing faster than XviD was :)

~misfit

[akupenguin]

Originally posted by Blue_MiSfit
So, ATM using 1 b-frame is all good, but with more than 1 we might see the evil blocking errors like I was getting with my Family Guy encode awhile back? yes. (The blocking is still a bug, I was just explaining why it occurred only some of the time.)

Is there any point in having more than 1 reference frame if you are only using 1 b-frame? # of reference frames is completely independent from # of B-frames. Multiple references always help, with or without B-frames. (But I haven't tuned it for B-frames. I might be able to improve total quality by spending more time on the reference search for P-frames and less time for B-frames.)

[ChronoReverse]

Strange bug I'm encountering. Very reproducible on both my AthlonXP boxes.

Take one avisynth script (640x480 anime DVD source @ 23.97FPS)
Add vdubmod 1.5.10.1
Fast Recompress mode
Stir in x264vfw rev. 113
*2-pass encode targetted at 612kbps
*Load Default Settings
*No Fast first pass
*Max reference frames: 12
*Max B-frames: 1
*Max IDR-keyframe interval: 240
*Min IDR-keyframe interval: 24

Set to simmer and encode using the Job Control.



Somewhere during the first pass, vdubmod invariably exits completely without warning. It doesn't happen with 3 bframes and 0 frames (with all other settings the same).

After I finish off this 1 bframe encode, I'll be trying the same settings with revision 112.

I'm currently also doing an encode with all default settings exception 1 bframe.


I tried it without job control and got this error dialogue:
http://img215.exs.cx/img215/5994/error1rn.gif



While I was comparing x264 to XviD, I noticed some things.

Source: http://img202.exs.cx/img202/1957/source7rf.png
XviD 1.1.0b: http://img202.exs.cx/img202/6515/xvid7wz.png
x264vfw rev.113: http://img202.exs.cx/img202/5663/x264r1135cn.png

First off, there's a line that only exists in the x264vfw. Weird, but I'm sure it's just one of those bugs that'll be fixed.

Secondly, x264 looks quite a bit better in this particularly frame. However, for most of the frames the XviD encode only has marginally more ringing than x264 and often more detail (it may be ffdshow, but the x264 encodes are slightly more blurry).
To be fair, the XviD encode was done using 3 bframes while the x264 encode was done using 0 bframes.

[akupenguin]

That assertion has been reported several times, and each time that I could verify anything at all, it turned out that the first pass logfile had been truncated. Maybe whatever the bug is, it's fatal if using jobcontrol, but silently ignores the error in a single encode?

[temporance]

I'm encountering a crash in x264 which, from the disassembly looks like it's an access violation in a MMX SAD routine somewhere.

I've built the binary using cygwin, so when I debug in MSVC I have no debug info so can't trace the bug.

Which is easier: have the cygwin build env generate debug info for MSVC, or build x264 using MSVC?

[akupenguin]

I refuse to have anything to do with MSVC, so I can't say which is easier. My choice would be to debug with GDB.
Have you determined whether it's a problem with MMX, and not bad inputs to the SAD function?

[Yong]

My question probably too stupid, :p
so i try myself comparing 2pass encoding with 3pass encoding,
the result is quite disappointed,
i found nothing is gain or lost in the 3pass mode, comapare with 2pass mode.

Here's how:
(example only, forgot to copy the encoding batch script :p, may be something wrong with my encoding step, if you don't thrust me, please try it out yourself, with mencoder or x264vfw)
2pass encoding
i use fast first-pass,
the use slow second pass, 800kbps.

3pass encoding
also fast first pass
slow second pass with 1600kbps,
slow third pass(same as second pass, but only the bitrate is change),800kbps.

the result is,
2pass encoded video is bit-identical to 3pass encoded video,
:eek: , please correct me if i'm do something wrong:D

[temporance]

Originally posted by akupenguin
I refuse to have anything to do with MSVC, so I can't say which is easier. My choice would be to debug with GDB.
Have you determined whether it's a problem with MMX, and not bad inputs to the SAD function? It's not a problem with MMX, as I expected. The crash seems to originate here:

/* try extra predictors if provided */
if (0) for( i_iter = 0; i_iter < i_mvc; i_iter++ )
{
const int mx = x264_clip3( ( mvc[i_iter][0] + 2 ) >> 2, mv_x_min, mv_x_max );
const int my = x264_clip3( ( mvc[i_iter][1] + 2 ) >> 2, mv_y_min, mv_y_max );
if( mx != bmx || my != bmy )
COST_MV( mx, my );
}
My hack-fix is in bold.

When i_iter=1 there are some extreme MVs. Hope this helps: if you want me to take a look further I can.

[akupenguin]

2pass encoded video is bit-identical to 3pass encoded video
You didn't enable "Update statsfile". (Either that or the vfw interface for it is broken, but I doubt it.)

And changing the bitrate between 2nd and 3rd pass completely defeats the purpose of 3pass encoding. It's suppose to refine the bit distribution, not start over from scratch.

[Yong]

Originally posted by akupenguin
You didn't enable "Update statsfile". (Either that or the vfw interface for it is broken, but I doubt it.)

And changing the bitrate between 2nd and 3rd pass completely defeats the purpose of 3pass encoding.

No test that much with x264vfw, but i'm sure the option "Update statsfile" is selected.

The test is done using mencoder 2005 FEB 01 compiled by celtic druid,
so how to use the 3pass encoding?
It's suppose to refine the bit distribution, not start over from scratch.
Which options to change?
Sorry i'm dumb and please theach me:D

[akupenguin]

Originally posted by temporance
When i_iter=1 there are some extreme MVs. Hope this helps: if you want me to take a look further I can. Are the MVs really extreme (i.e. uninitialized data, which would be a separate bug), or just point a little bit outside the picture?
Either way, I think I have fixed the crash.

[akupenguin]

Originally posted by Yong
The test is done using mencoder 2005 FEB 01 compiled by celtic druid,
so how to use the 3pass encoding? In that case, it's simple: "pass=2" means 2 pass encoding. "pass=3" means N pass encoding.
A 3 pass encode consists of one encode with fast settings and pass=1, followed by two encodes with identical slow settings and pass=3. (You don't have to stop at 3 passes, but any further is pointless.)
Which options to change? Don't change anything between the 2nd and 3rd passes. (In the interest of speed, you should be able to get away with a slight change in subq or frameref, but I haven't done any rigorous tests of that.)

For an example (which does tweak subq and frameref), see the shell scripts in virus' x264 pack for cygwin (http://forum.doom9.org/showthread.php?s=&postid=603606#post603606)

[Yong]

Originally posted by akupenguin
In that case, it's simple: "pass=2" means 2 pass encoding. "pass=3" means N pass encoding.
A 3 pass encode consists of one encode with fast settings and pass=1, followed by two encodes with identical slow settings and pass=3. (You don't have to stop at 3 passes, but any further is pointless.)
Don't change anything between the 2nd and 3rd passes. (In the interest of speed, you should be able to get away with a slight change in subq or frameref, but I haven't done any rigorous tests of that.)

For an example (which does tweak subq and frameref), see the shell scripts in virus' x264 pack for cygwin (http://forum.doom9.org/showthread.php?s=&postid=603606#post603606)

Thanks for the replies,
i'll try out later:D

[temporance]

Originally posted by akupenguin
Are the MVs really extreme (i.e. uninitialized data, which would be a separate bug), or just point a little bit outside the picture?
Either way, I think I have fixed the crash. I think they were just a little bit outside the picture.

[Sharktooth]

Rev 114 binaries: outdated

Rev 114 WFV installer: outdated

This is not celtic_druid build. There are both the VFW dll and commandline encoder. Compiled with gcc and nasm with default asm and c flags.
It may not work since it's the first time i compile x264. However, no, it won't make your computer explode... :)

EDIT: updated with NDEBUG=1 option.
EDIT2: added nsis installer version.

[hpn]

Just did a fast 2-pass encode (quality settings maxed up) and your rev114 build works fine, although the x264vfw.dll is now twice as big as the one in build 113 (972K compared to 406K). The encoding speed is the same, so I hope the dll size doesn't matter too much and only depends on the way one compiles it.

Edit: tested again with the new build (dll is now 362K only!) and it works fine again. A bit by bit comparison proves that both encodes are identical, not that I expected something else, but just to make sure :)

[virus]

@Sharktooth:
better if you use "make NDEBUG=1" for both the core and the vfw. You'll end up with much smaller files.

I'll update my pack very soon with rev. 114. You'll be able to find it both at the usual address as well as Tobias' mirror (http://www.iti.uni-stuttgart.de/~bergmats/video_mirror/videotools/) (which is very fast btw).

I hope to be able to add other goodies to it in the near future - spyder sent me some scripts/tools for automated AVS2MP3 conversion, which can be tweaked for AAC too. Also nls is working on a commandline calculator (based on XviD code) which may be worth inclusion. Maybe I can manage to do a full rip with a single command... ;)

EDIT: find it here (http://www.webalice.it/riccardo.stievano/video_stuff/x264-encpack-r114.zip).

[gotaserena]

Funny, my cross-compiled version has 419kb... I wonder how fast it is, when compared to celtic_druid's...

Better spend more time in my win box! :D

[Sharktooth]

Originally posted by virus
@Sharktooth:
better if you use "make NDEBUG=1" for both the core and the vfw. You'll end up with much smaller files.
i thought i did it...
... re-making

EDIT: udpdated. filesizes are ok... now.

[ChronoReverse]

Load Defaults button doesn't visibly do anything.

@Akupenguin

That assertion has been reported several times, and each time that I could verify anything at all, it turned out that the first pass logfile had been truncated. Maybe whatever the bug is, it's fatal if using jobcontrol, but silently ignores the error in a single encode?
I have no idea, but the crash also occurs in the first pass too in some situations (again perfectly reproducible).

[Sharktooth]

load defaults should affect advanced options only.

[JoeBG]

Originally posted by virus
@Sharktooth:
better if you use "make NDEBUG=1" for both the core and the vfw. You'll end up with much smaller files.

I'll update my pack very soon with rev. 114. You'll be able to find it both at the usual address as well as Tobias' mirror (http://www.iti.uni-stuttgart.de/~bergmats/video_mirror/videotools/) (which is very fast btw).

I hope to be able to add other goodies to it in the near future - spyder sent me some scripts/tools for automated AVS2MP3 conversion, which can be tweaked for AAC too. Also nls is working on a commandline calculator (based on XviD code) which may be worth inclusion. Maybe I can manage to do a full rip with a single command... ;)

EDIT: find it here (http://www.webalice.it/riccardo.stievano/video_stuff/x264-encpack-r114.zip).

And it´s great. Testet it already. Thank you very much.

[Sharktooth]

Ok, celtic_druid built the rev114 too.
It's at the usual place (already mirrored)
Next builds will have an installer :)

[virus]

thx JoeBG :)

Since I plan to keep the mencoder pack updated (and even expand it with additions), I thought about setting up a small webpage to keep you informed, without the need to spam this forum for each tiny change/update :D

I won't do builds for all revisions. I've already skipped revs 111 and 113 because they were purely cosmetic, and didn't change the encoder at all. So I'm going to do meaningful updates only ;)

I'm a total n00b at HTML, but anyway here (http://www.webalice.it/riccardo.stievano/video_stuff/x264.html) you can find my own x264 page (with a link to the encpack). I hope to expand it in future... I also have some plans of writing some decent documentation for x264 ("decent" means "TeX" for me, not "Word", just to make it clear): how to get the sources, how to compile, what encoding options to choose and so on. Someday maybe I'll find the time...

virus

[akupenguin]

Originally posted by ChronoReverse
I have no idea, but the crash also occurs in the first pass too in some situations (again perfectly reproducible). Not possible. Ratecontrol doesn't even run on the 1st pass. (I'm not saying there aren't other possible crashes, like the one I just fixed.)

[ChronoReverse]

I'm not referring to the Assert Error, if that's what you meant. It's the other crash where vdubmod just disappears.


In any case, it didn't seem to happen with revision 114 so it's a moot point.

[Sharktooth]

x.264 VFW rev.115 win32 binary with NSIS installer: outdated

Changes:
r114 didn't completely fix the problem, trying again.

Notes:
compiled with gcc and nasm and default c and asm flags.

[DLMunson]

WOW, i just tried x264(115) and DAMN. i couldnt tell difference from the original dvd, sure i use high bitrates(1500-1700 for video) but it looked perfect, while xvid (1.0.3, 1.1.0beta) had some blocking, artifacts or whatever you call them, im a complete n00b to videoencoding :(

for being so early in development this codec was flawless, no crashes and quality was sick. mad props to all the people workin on this. too bad its 1/30 the encoding speed. but oh well its worth it.

[Yong]

@akupenguin:
You say don't change the options between 2pass and 3pass,
i tried with x264vfw and mencoder,
still same result,
2pass encoded video file size are bit-identical to 3pass encoded
:(

[Sharktooth]

That means the ratecontrol just did it's job in the second pass.
You should be happy with that :)

[temporance]

That looks like a MMX SAD algo, and very similar to the code where I was seeing my predictor-candidate related crash (now fixed, thanks). Could there be other sources of rogue MV candidates?

[akupenguin]

Originally posted by Yong
i tried with x264vfw and mencoder, still same result, 2pass encoded video file size are bit-identical to 3pass encoded What can I say? Works For Me.

Originally posted by Sharktooth
That means the ratecontrol just did it's job in the second pass.
You should be happy with that :) No, it isn't that precise. Even if the N+1th pass can't improve the distribution, it still won't be bit-identical.

[Sharktooth]

btw, nth pass is evil. 2 passes should be enaugh (as in xvid).

[akupenguin]

2 passes is enough. But that's no reason not to offer Nth pass, when all it takes is one checkbox (no extra code in the core). If nothing else, it provides a means to test the accuracy of the 2pass rc. And it will become more useful when multipass is used for more than just ratecontrol.

[digidragon]

I'm using rev 115 and when trying to encode an avisynth file in vdubmod I get "Cannot start video compression - maybe corrupt data (error code -100)".

After a bit of playing, it seems to be the crop and resize functions (either of them) in the script that cause the error.

These are the two relevant lines in the avs file:

crop(6,16,712,548)
LanczosResize(712,376)

Apart from not cropping or resizing, is there a workaround?

[stephanV]

keep your res mod16 (712,376 is mod8)

[digidragon]

Thanks - the error seems to have gone now.

I did check in the codec properties first, and the only format restrictions mentioned were about colour depth...

[Yong]

@akupenguin:
It's work for you?

Here's my encoding batch script:
start /b /low /w mencoder %1 -noskip -nosound -o nul: -ovc x264 -x264encopts keyint=300:nocabac:nodeblock:no4x4mv:nob8x8mv:no8x8mv:subq=1:bframes=3:pass=1:qp_constant=18 -passlogfile "x264.log"

start /b /low /w mencoder %1 -audio-preload 2.0 -noskip -nosound -o "%temp%\temp.avi" -ovc x264 -x264encopts keyint=300:frameref=15:nodeblock:deblockalpha=-6:deblockbeta=-6:ip_factor=1.4:pb_factor=1.3:cabacidc=2:scenecut=40:cabac:8x8mv:4x4mv:b8x8mv:direct_pred=2:subq=5:qp_step=3:rc_sens=1:qp_min=10:qp_max=51:pass=2:bframes=3:bitrate=800 -passlogfile "x264.log" -ffourcc X264

start /b /low /w mencoder %1 -audio-preload 2.0 -noskip -oac copy -o "%temp%\temp.avi" -ovc x264 -x264encopts keyint=300:frameref=15:nodeblock:deblockalpha=-6:deblockbeta=-6:ip_factor=1.4:pb_factor=1.3:cabacidc=2:scenecut=40:cabac:8x8mv:4x4mv:b8x8mv:direct_pred=2:subq=5:qp_step=3:rc_sens=1:qp_min=10:qp_max=51:pass=3:bframes=3:bitrate=800 -passlogfile "x264.log" -ffourcc X264

Output info by mencoder, Second Pass:

Video stream: 800.819 kbit/s (100102 bps) size: 15856213 bytes 158.400 secs
4755 frames
x264 [info]: slice I:37 Avg QP:17.95 Avg size: 8967
x264 [info]: slice P:1359 Avg QP:19.63 Avg size: 6157
x264 [info]: slice B:3354 Avg QP:21.52 Avg size: 2127
x264 [info]: slice I Avg I4x4:58.8% I16x16:41.2%
x264 [info]: slice P Avg I4x4:13.7% I16x16:7.1% P:47.4% P8x8:16.7% PSKIP:1
5.0%
x264 [info]: slice B Avg I4x4:1.3% I16x16:0.8% P:24.8% B:17.6% B8x8:10.0%
DIRECT:9.0% BSKIP:36.5%
x264 [info]: kb/s:799.9

Third Pass:

Video stream: 800.819 kbit/s (100102 bps) size: 15856213 bytes 158.400 secs
4755 frames
x264 [info]: slice I:37 Avg QP:17.95 Avg size: 8967
x264 [info]: slice P:1359 Avg QP:19.63 Avg size: 6157
x264 [info]: slice B:3354 Avg QP:21.52 Avg size: 2127
x264 [info]: slice I Avg I4x4:58.8% I16x16:41.2%
x264 [info]: slice P Avg I4x4:13.7% I16x16:7.1% P:47.4% P8x8:16.7% PSKIP:1
5.0%
x264 [info]: slice B Avg I4x4:1.3% I16x16:0.8% P:24.8% B:17.6% B8x8:10.0%
DIRECT:9.0% BSKIP:36.5%
x264 [info]: kb/s:799.9

The Secondpass and Thirdpass x264 [info] were same.
I tried many time, with mencoder and x264vfw, the result were same, may be something wrong in my batch encoding script...
I can't believe why it couldn't wotk for me...

[akupenguin]

Originally posted by Yong
pass=2
That's exactly what I told you not to do:
Originally posted by akupenguin
In that case, it's simple: "pass=2" means 2 pass encoding. "pass=3" means N pass encoding.
A 3 pass encode consists of one encode with fast settings and pass=1, followed by two encodes with identical slow settings and pass=3.

[Yong]

@akupenguin:
Ok, actually my batch script will have rem(remark) at the start of batch script.

Here's my encoding work:
1. Only the first line of batch script are active,
Second and third pass is disabled, after that will backup the stats file.

2. Only the second pass are active.

3. Only the the third pass are active.

4. Then i will end up a 2pass encoded and 3pass encoded video.(for comparing)

I have three questions,
Is second pass encoding read the stats file only?
Then thrid pass will read and overwtrite the stats file?
So the 3pass encoding batch script is look like this?
Or one 3thpass encoding command only?

start /b /low /w mencoder %1 -audio-preload 2.0 -noskip -nosound -o "%temp%\temp.avi" -ovc x264 -x264encopts keyint=300:frameref=15:nodeblock:deblockalpha=-6:deblockbeta=-6:ip_factor=1.4:pb_factor=1. 3:cabacidc=2:scenecut=40:cabac:8x8mv:4x4mv:b8x8mv:direct_pred=2:subq=5:qp_step=3:rc_sens=1:qp_min=10:qp_max=51:pass=3:bframes=3:bitrate=800 -passlogfile "x264.log" -ffourcc X264

start /b /low /w mencoder %1 -audio-preload 2.0 -noskip -oac copy -o "%temp%\temp.avi" -ovc x264 -x264encopts keyint=300:frameref=15:nodeblock:deblockalpha=-6:deblockbeta=-6:ip_factor=1.4:pb_factor=1. 3:cabacidc=2:scenecut=40:cabac:8x8mv:4x4mv:b8x8mv:direct_pred=2:subq=5:qp_step=3:rc_sens=1:qp_min=10:qp_max=51:pass=3:bframes=3:bitrate=800 -passlogfile "x264.log" -ffourcc X264

You say it's work for you(you are on linux, right?),
but now i can confirm the vfw "update statsfile" doesnt work,
Anyone try it before?

[virus]

Originally posted by Yong
but now i can confirm the vfw "update statsfile" doesnt work,
Anyone try it before?
Works For Me(TM)

500 frames, *very* difficult scene, target 800 kbit/s:

2-pass: 697 kbit/s
3-pass: 804 kbit/s
4-pass: 801 kbit/s

(that also shows the point of multipass: correcting the target size on short clips, when they come out heavily oversized/undersized. On long encodes it's usually not necessary)

virus

[Sharktooth]

ok, at this point i should ask if nth pass (even if "it's evil(TM)":p) is going to be implemented in vfw interface... :D

[virus]

Originally posted by Sharktooth
ok, at this point i should ask if nth pass (even if "it's evil(TM)":p) is going to be implemented in vfw interface... :D
it has been there since revision 105... :rolleyes:

(that's exactly the purpose of the "update statsfile" checkbox, it allows to rerun the 2nd pass as many times as you want reusing the stats from the previous pass, making it effectively a multipass encoding. The test above has been done using the VfW frontend)

[Sharktooth]

good! maybe renaming "2nd pass" with "Nth pass" in the vfw frontend... ;)

[Yong]

Originally posted by virus
Works For Me(TM)

500 frames, *very* difficult scene, target 800 kbit/s:

2-pass: 697 kbit/s
3-pass: 804 kbit/s
4-pass: 801 kbit/s

Wierd, i tried many times, with VDmod,
It must be something worng in my computer.(or my brain):mad:

I also uncoverd a bug, the option: frameref, always keeping crash form me(TM):D, when the value is 15, for some MPEG1 clips at certain percentage.
i tried lowering the value, also crash but more faster.(frameref=15 will crash at 75%, 5 will crash at 30%),
same as mencoder.

Sorry if i'm bring more troboule to this forum, or the x264 devs...

EDIT:
1. the frameref crash problem only occured in the mencoder compiled by celtic druid(but not the celtic druid fault).:p
2.(that also shows the point of multipass: correcting the target size on short clips, when they come out heavily oversized/undersized. On long encodes it's usually not necessary)
I think virus already answered my question,
i tried, it works, but only for short clips(500 frames)...
i tried full lenght(around 4000 frames only), with frameref=15,
all macroblock partition options were selected, still same result, may be not so effective if frameref=15 or something else...

[rushin_911]

To the developers of the codec, thx alot :) I really like how its going, and since I only encode for one cd it is becomming my codec of choise for many of those hard-to-encode anime...

I would like to, however, request the implamantation of Aspect Ratio support... It would be a really good feature :)

[Sharktooth]

Build 117 is up in the main celtic_druid's mirror.

- Changes:
VfW: use separate stats files for each pass of an N-pass encode.

- Revision 116 changes:
VfW: Enable multipass by default, increase the configurable range of I and B quant ratios.
core: Tweak error messages.

[hpn]

I just posted some screenshots using the new revision 117 (plus the latest Nero and XviD counterparts). It's a free hosting, so I guess the links will be down very soon (I'll remove them from the thread if needed)

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

Edit: Feb.13 - the speed table is updated with revision 123 (~25% speed boost, compared to rev 117, both 117 and 123 builds deliver identical picture quality)

[ermannob]

Very nice test, hpn!

What about those parameters about max reference frames and max b-frames? Are they good for standard use, or are they test-specific?

[baer999]

I just saw the few screenshots and it's amazing how near the Codec pictures are on the original! I couldn't see big differences.
I've got a little Question :
Is that right "Nero H.264 Codec is much better then the x264" ?

[Ark]

@ermannob

You can safely use as many reference frames as you want up to the max (15...for now??), but b-frames are a little more tricky.

For now they lack adaptiveness and aren't deblocked, so (from some tests done by many users here), the suggested value is 1 max or nothing at all.

Btw, i think that x264 wins over Nero (by a small amount though) in low motion and stays behind it in fast motion (more noticeable here)... but there's room for improvement for both of them...

[len0x]

Originally posted by baer999
Is that right "Nero H.264 Codec is much better then the x264" ?

where did you get this from?

[baer999]

I've read it in some Threads that Nero is 2 / 3 quicker or something like this ! And Quality should be better too

[len0x]

You shouldn't trust what you read - you have to see the difference with your own eyes... (and I've heard the opposite about speed btw, but I never used Nero myself).

P.S. you might also be confusing Nero ASP with Nero AVC, coz Nero AVC simply cannot be 3 times faster than x264.

[Sharktooth]

x264 is faster than nero (sometimes even 2 times...) with the same settings (i always use 5 reference frames though...) but as ark said it still has not "adaptive b-frame" feature.
So dont use multiple b-frames or do not use b-frames at all.
For what concerns the final quality it cannot be compared for the above reason.
Try to encode both clips without b-frames for both the encoders and then you can draw some conclusions.

[virus]

watching the comparison posted by hpn, I saw something that catched my attention: revision 117 with the "update statsfile" disabled. It's now on by default (hit Load Defaults and see) but I think a brief explanation of why it has been enabled is in order.

Starting with revision 117, VfW automatically handles the statsfile name for you (that's why you aren't allowed to change its name during the Nth pass anymore, but only before the 1stpass). From now on x264 will never overwrite a statsfile previously created during previous passes of the same encode, so it won't be damaged if a crash happens. Let's see how the naming scheme works, using the default name (x264.stats) as an example:

1st pass:
input: none
output: x264-1.stats

2nd pass:
input: x264-1.stats
output: x264-2.stats

3rd pass:
input: x264-2.stats
output: x264-3.stats

...at this point you should start to see a pattern :D

That means that if you leave "update statsfile" enabled, you will still be able to see/use your original 1stpass statsfile if you need it. But that will also give you an important opportunity: if after 2 passes your target size has not been hit with enough precision, you can easily run another pass and improve it. In Vdub, that means simply pressing F7 and then OK, without the need for changing anything.

If you leave the checkbox disabled, you'll be forced to open the dialog, enable the checkbox, and then run both the 2nd pass (again) as well as the 3rd. That's why it's good to leave it always enabled. You have nothing to lose, and sometimes it will be very handy ;)

Oh btw... when you do a new encode using again the same filename in the same directory, x264 will delete automatically all previously created statfiles for each pass with the same name (in our example all three x264-*.stats would be deleted and a new file x264-1.stats would be created). So make sure to use a different name or rename them after the encoding if you want to keep them for future use ;)

hope this helps :)
virus

[Doom9]

but b-frames are a little more tricky.
For now they lack adaptiveness and aren't deblockedI guess we should have a x264 roadmap sticky so we can cross things off the list as they are implemented..
RDO would also have to be placed on that list, and I guess optimization for speed (using comparable x264 settings as for ateme AVC in the codec comparison, the latter is definitely faster on my box.. though by how much I cannot say at this point as I never leave the PC unattended during encoding except for codec comparisons).
And then there's the decoder part though I figure that's a low priority item.
What about weighted prediction?

@virus: good explanation :)

[Sharktooth]

@Doom9: on my machine (athlon xp) x264 is faster than Recode expecially in the second pass when sometimes x264 is twice as fast...

[Manao]

x264 is faster than nero (sometimes even 2 times...) with the same settings I seriously doubt that ( even with 5 references ). And anyway, the only thing that matters is speed comparison at same quality settings, not same settings ( different encoders -> different handling of the settings which can lead to different final quality ).

Doom9 : imho, RDO should be the priority, followed by adaptive bvop. Weighted prediction is cool stuff, but not that easy to use, and only really usefull in fadein / out which tends to occur only in trailers. I'd add FRext on the todo list with a higher priority than weighted prediction. The decoder is more advanced than the encoder, since ffmpeg decodes weighted prediction already. It still lacks bvop deblocking, though.

[baer999]

Ok now it seems that x264 is the new codec for me, but as I can see it is at the beginning and their are many improvements to do. When I want to make well looking Rips how long should I wait, or how much time does the bvop and RDO need (only a prediction). I think that will make the codec much better and because of this I don't want to make my Backups now ...

[Sharktooth]

Ok, im going to measure encoding time for both the codecs.

[Sharktooth]

Test is finished. X.264 is FASTER.


Source: Spiderman 2 trailer (DVD source)

Settings:
Ref Frames=5
B-Frames=1
Deblocking Strenght=0
All options enabled

Avisynth script:
# VIDEO SOURCE
Mpeg2Source("sp2tr.d2v", idct=2)

# CROPPING
Crop(0,14,720,548)

# RESIZING
LanczosResize(720,384)
The same script was used for both the encodes to ensure they were not influenced by a different code for mpeg2 decoding and resizing.


Encoding speed details for Nero Recode:
1st pass 2nd pass
Time(m,s) 11,08 11,04
Av. FPS 4.52 4.55

Encoding speed details for x.264:
1st pass 2nd pass
Time(m,s) 5,43 7,06
Av. FPS 8,82 7,10

[Doom9]

you guys obviously don't have the same ateme AVC encoder as I do ;) I guess you still don't get 31 fps for a full lenght movie (AVS input with no resizing). I'm not even sure if you can make Recode not do any preprocessing prior to encoding. And as you might know, I have an Athlon 64 3500+ (ateme's encoder should perform better on Intel processors afaik).

When I want to make well looking Rips how long should I wait,is a really uncool statement as it implicitly tries to push developers to give you what YOU want right now. You need to learn to live with what you got. And just as much as there'll always be newer codec builds, there'll always be new hardware, so you should never encode your movies and never buy new hardware ;)

[Doom9]

@Sharktooth:I'm afraid you'll have to do full movie encodings. As stated in the codec comparison, ateme's AVC encoder uses a to be patented technique that makes the first pass gradually speed up (look at my encoding speed numbers in the comparison. you'll see there's a significant difference between a 10'000 clip and the full movie).

[Sharktooth]

Ok, but what about the second pass?
The difference is still there and btw i didnt use "fast first pass" for x.264.
I dont want to be harsh but... patented or not nero seems slower than x.264 to me.

EDIT: btw we're talking of RELEASED software.

[Manao]

Sharktooth : what encoding settings ( especially, what quality settings ) did you choose with nero ? Because i can say that Divx is faster than XviD, if, let's say, i compare vhq4 + bvhq + trellis on one side, and fastest mode on the other side.

[Sharktooth]

I enabled and maxed out everything in both x264 and recode (except the settings below).
I used the same reference frames (5), same bframes (1), and same deblocking strength (0) for both.

[Manao]

Good, Best and Extra mode in Nero uses RD optimizations, which aren't yet implemented in x264, and which are slow. If you want to compare Nero and x264, you should use normal mode for nero.

[Doom9]

Ok, but what about the second pass?If you have > 100 fps in the first pass, that makes a sizeable difference ;) I get about real-time encoding using fast first pass in x264, and the 2nd pass is obviously quite a bit slower. Anyway, prior to the next codec comparison it's too early to compare speed ;)

[Sharktooth]

... so if i want to compare xvid to divx i should disable vhq for b-frames, trellis quant, custom matrices... etc etc.
Every codec has its features and since the x.264 encode looks better (even without the fancy RD optimizations) i consider enabling all options in nero the only way to be close in quality to x.264.
So, no thanks, i wont disable anything or the comparison will not be fair.
Originally posted by Doom9
If you have > 100 fps in the first pass, that makes a sizeable difference ;) I get about real-time encoding using fast first pass in x264, and the 2nd pass is obviously quite a bit slower. Anyway, prior to the next codec comparison it's too early to compare speed ;)
Well you dont get realtime encoding... you get 30fps at the end of first pass.
Take note of the number of frames, the time needed for the first pass and manually calculate the average FPS (that's what i've done in my comparison) then draw your conclusions.
For example, nero recode reported 9fps at the end of first pass and "wanted" me to believe that was the encoding speed... If math it's not an opinion, that was not true.

[Doom9]

@Sharktooth: I think you are just misunderstanding me here > 100 fps is encavc's first pass fps (encoding time in seconds/frames), the 31 or so fps is encoding time for both passes divided by twice the number of frames. Now, once again, in order to compare FPS you need to do full movie encodings.. everything else is just plain useless.

And in my vocabulary, real-time encoding = average fps > fps of the source. Your definition may vary, but at the end of the day, > 2x realtime = encoding a movie in two pass mode takes less long than watching the movie imho makes a lot of sense.

[Sharktooth]

whole movie encoding test coming soon...

[virus]

Originally posted by Manao
imho, RDO should be the priority, followed by adaptive bvop. (...) I'd add FRext on the todo list with a higher priority than weighted prediction. The decoder is more advanced than the encoder, since ffmpeg decodes weighted prediction already. It still lacks bvop deblocking, though.
oh, it's feature request time, let's join the party :D

My PSNR tests told me that: the most important thing right now is bvop adaptivity. It will bring a considerable quality boost with a (hopefully) limited increase in complexity. After that, I rate as second the use of bvops as references (but that requires bvop deblocking in lavc or the decoding will b0rk). Both of these are tasks where sysKin can throw his experience in ;)

After those 2, imho it's debatable. When I complained with akupenguin because he set subpel ref. to 5 as default (the slowest setting), he told me that it's not really slow... "wait and see when I add R/D optimization". Lesson learned: R/D will improve things, but with a considerable slowdown, so I don't hold my breath for it :)

That makes me think that a bit of general speed optimization may be in order before R/D becomes usable (speed-wise). But to do speed optimization, maybe it's needed to fully stabilize bvop implementation first (by adding all modes down to 4x4 and maybe other minor things I don't know). Also, currently bvops don't have a proper ratecontrol (just an offset from pvops), so maybe a bit of tweaking of the RC may be needed to fully exploit them, too. New MB modes, mode decision improvements, R/D and RC tweakings are well-suited to aku ;)

As for weighted prediction, I think it will be slow (on the encoding side) and provide very marginal gains - much like XviD's GMC - so I totally agree with Manao on that. As you can see, there's already quite a bit of work for the core devs, and I haven't even mentioned High Profile... :D

(disclaimer: of course aku and sysKin are totally free to ignore all this and work on anything they want... so guys just have fun hacking x264)

EDIT: typos fixed...

[Sirber]

Keep the great work :D

[akupenguin]

Actually, no, weighted prediction should be fast. In B-frames it doesn't add any analysis complexity, just an alternate averaging function (only ~4% of the decoding CPU-time in lavc even without MMX). In P-frames it takes only one least-squares fit to determine whether a frame can use weighting, so that should be about the same speed as the PSNR calculation (~3% CPU-time at the fastest settings, comparitively less at slow settings). (Yes, I have implemented that part in a deflicker filter, just not in x264.) And since weighted P-frames are probably rare, it's not a big deal if they're slow to encode. On the other hand, XviD has to do a full motion estimation pass to even decide whether to use GMC.

As for B-frame ratecontrol: I used to give them the same overflow treatment as P-frames. That ended up slightly closer to the target bitrate, but much worse quality. A fixed quant ratio is the best quality per bitrate, and there are better ways to improve prediction.

[hpn]

Originally posted by virus
watching the comparison posted by hpn, I saw something that catched my attention: revision 117 with the "update statsfile" disabled. It's now on by default (hit Load Defaults and see) but I think a brief explanation of why it has been enabled is in order.
virus

Yes, virus is absolutely right. It's a good idea to always keep the "update statsfile" checkbox enabled during second pass. I was aware of that and unchecked it only because I was absolutely sure I'd run a 2-pass encoding only and simply didn't need any extra files (in this case x264-2.stats). Note that in case of 2-pass encoding only, it doesn't matter whether you have 'update statsfile' checkbox enabled or disabled during the second pass. In both cases the resulting encodes after the second pass will be bit-by-bit identical.

[Sharktooth]

Revision 118 win32 vfw with installer is here: outdated

Changes:
VfW: tweak option names

Notes:
Compiled with gcc and nasm with default flags and NDEBUG=1 option.
This revision will produce bit-to-bit identical encodes to rev. 117. The only differences are in some option names in the vfw config dialog.

[temporance]

Originally posted by Doom9
@Sharktooth:I'm afraid you'll have to do full movie encodings. As stated in the codec comparison, ateme's AVC encoder uses a to be patented technique that makes the first pass gradually speed up (look at my encoding speed numbers in the comparison. you'll see there's a significant difference between a 10'000 clip and the full movie). If they haven't filed the patent yet, then it's too late to do so, because they've already released code containing their invention. Anyone got a link to the patent application, or a description of this technique? Sounds interesting, maybe xvid/x264 could use it. Yes I know it might be patented, but so is all of MPEG-4 ;)

[nicco]

Originally posted by Doom9
I guess we should have a x264 roadmap sticky so we can cross things off the list as they are implemented..


I agree!

[Doom9]

as far as the roadmap goes, here it is: http://students.washington.edu/lorenm/src/x264/todo.txt

[baer999]

Oh well there are many improvements left :)
how many coders are active in this project and what language (C++???) is it ?

[iapir]

Originally posted by Doom9
as far as the roadmap goes, here it is: http://students.washington.edu/lorenm/src/x264/todo.txt


Interresting, there's not even a mention of VfW or AVI limitations, compared to the possibilities of AVC...

[Sharktooth]

Those "limitations" can be worked around.
AVI shouldnt accept b-frames and vbr audio too... but someone managed how to put it in...

[Doom9]

Interresting, there's not even a mention of VfW or AVI limitations, compared to the possibilities of AVC...x264 is container agnostic. In fact, the recommended way of using it is in mencoder, which can deliver raw streams that can be muxed into MP4 or another suitable container. In the future, there might be mpg output as well. As soon as a suitable spec compliant AVC capable MP4 muxer is released, I'll add MP4 output to my mencoder GUI (it's quite powerful so perhaps MP4 output will make you want to forget about VDub, who knows).

[JoeBG]

Originally posted by Doom9
As soon as a suitable spec compliant AVC capable MP4 muxer is released, I'll add MP4 output to my mencoder GUI (it's quite powerful so perhaps MP4 output will make you want to forget about VDub, who knows).

Yes...and many people are waiting for this ;)

[bond]

mp4creator should mux x264 bitstreams into .mp4 perfectly (tested it a lot recently)

it muxes from raw, but that shouldnt be a problem as mencoder can also output raw video streams

[Doom9]

there's more: an mp4muxer needs to be able to split the output at a predefined size... else.. no > 1 CD rips.

[TheBashar]

Originally posted by Doom9
as far as the roadmap goes, here it is: http://students.washington.edu/lorenm/src/x264/todo.txt

I was wondering if there was any hope of getting zones support on the roadmap.

[BoNz1]

Originally posted by TheBashar
I was wondering if there was any hope of getting zones support on the roadmap.

While I definitely don't speak for any of the x264 developers IMO it is more important to concentrate on making improvements to the core before adding things like zones.

[defunkt]

I think it's possible to implement a rudimentary zones capability without distracting the x264 dev(s) from the really important stuff. avs2yuv (for instance) has command line range parameters (or one could use Trim() in the script itself), so it can be used to pipe only portions of an avs source to mencoder. its then fairly simple arithmetic to apply weights (i.e. 0.25, 1.25 ala xvid) to the average bitrate over the whole length of the encode. If output as a raw x264 stream, each portion (encoded with its own bitrate) is then joined with a binary copy (i.e. copy /b enc_01.264 + enc_02.264 + enc_03.264 = encode.264) before muxing. Messy I know, but its all possible with the tools available now. In an ideal world, a bitrate calculator with this feature could be incorporated into a frontend like Doom9's.

What's really needed is some solid data about mp4 overheads.

[akupenguin]

Multiplying the target total bitrate by some number isn't at all the same as a weight (though it is a valid zoning option). If you're going to write a frontend to do this funky splitting and separate encoding, that probably involves more coding that just implementing zones the right way. And you don't have to know anything about H.264 internals to add zones: the ratecontrol functions are separate.

[defunkt]

I'd love to help out with something that doesn't involve deciphering an MPEG RFC & I don't mind using C (from the safety of a M$ IDE) but getting complex multi-platform projects to compile does my head in.

One other advantage of encoding in portions is that it breaks down the total encode time into something manageable on my 1.3 Duron.

[Sharktooth]

rev 120 vfw with installer is here: outdated

Changes:
(r119) bs_align_1() didn't actually write all ones. (so encoded streams with cabac were technically invalid, though no decoder cares.)
(r120) cosmetics

Notes: usual build made with gcc + nasm and default flags + NDEBUG=1.

[akupenguin]

@defunkt:
If you want to try adding zones, consider the beginning of x264_ratecontrol_start() (ratecontrol.c:348) for CQP 1st pass, and the end of get_qscale() for the 2nd pass. (Don't bother adding zones to 1-pass CBR.) Actually weighting or forcing quants should be easy; most of the work would be in the graphical interface if you want to control zones via VfW.

As for your IDE: At some points in the past, x264 has been compiled with MSVC. I don't know if the project files are up to date, since all the published x264vfw builds are now done with gcc.

[defunkt]

@akupenguin

Thanks for the pointer. Actually I've been working on getting it to compile (as a standalone windows dll with exported API style encoding function and status callback - not vfw) and think I'm close though I still need to make a simple client to test it. This done I thought I'd try & incorporate the avs2yuv source (you wrote this?) as a way of doing away with the command line piping and mencoder. Then maybe a zones GUI. Hopefully I'll be in touch soon. ;)

[Doom9]

@defunkt: I thought there's a mencoder patch that already adds avs input. Just so that you don't reinvent the wheel.

[hpn]

Can somebody please explain why I get different first pass stats files (and of course second pass encodes later) when using different versions of VirtualDub: 1.5.10.1 build 2439 and the experimental version 1.6.4 build 23174 (both available at http://www.virtualdub.org/ ). I run a very short avs scrypt (100 frames) for these tests and of course exactly the same x264 settings for both VDub versions, while encoding. On top of that I can't get identical results when running a third test, MANUALLY encoding the same script in VirtualDub build 2439, and when I run the script (and exactly the same bitrate and x264 options) through GKnot that uses the same! VDub 2439 build. Encoding 100 frames takes only a few seconds, so I'll appreciate if someone wants to run these 3 different encodes and confirm (or deny) my observations and explain to me what I'm doing wrong or missing. You could use any frame number or bitrate for these tests.

In the third test when encoding 100 frames in GKnot, aiming at a specific bitrate, in Bitrate tab I check "calculate Avi file size" instead of the default "Calculate average bitrate", then put 1000kBit/s in the "Average Bitrate" field. Then you'll notice that the x264 second pass target bitrate is set by GKnot to 1024kbps (1024b vs. 1000b, depending on the conversion system developers prefer). Then I manualy replace the KGnot generated avs scrypt with my 100 frames scrypt and then click "Start encoding". The GKnot setting files "06_1_firstpass.settings" and "06_1_secondpass.settings" both contain the "passbitrate"=dword:00000400" line (400 HEX = 1024 Dec), so I suppose GKnot really encodes using VDub and x264 at exactly 1024kpbs (but I maybe wrong here, only len0x can confirm). However when I try to MANUALLY encode the same avs scrypt in the same VDub build at 1024kpbs I get completely different first pass stats file (always using Total Commander "Compare By Content" function for side-by-side file comparison).

The avs:

LoadPlugin("C:\PROGRA~1\GORDIA~1\DGMPGDec\dgdecode.dll")
mpeg2source("g:\t\06.d2v")
trim(40104,40203)
crop(0,72,720,432)

Just for the record, all previous builds of the 1.5.XX.XX branch (I also tried one+ year old build 2366) seem to deliver identical to the latest build 2439 encodes. Also 1.6.4 = 1.6.3. I was about to publish some more extensive Nero-x264 and x264-x264 (not a mistake) codec comparison, but was dissuaded after noticing that my resulting encodes depend not exclusively on the x264 build, but also on the encoding tool I'm using.

[len0x]

Bitrate makes no difference for first pass stats files as you don't have this setting available during first pass, so it must be something else...

[sysKin]

Originally posted by hpn
Can somebody please explain why I get different first pass stats files (and of course second pass encodes later) when using different versions of VirtualDub: 1.5.10.1 build 2439 and the experimental version 1.6.4 build 23174 (both available at http://www.virtualdub.org/ ).(...)
Just guessing, but:
- vdub 1.5 uses YUY2 (not sure) for its "fast recompress" colourspace.
- vdub 1.6 uses YV12
- when you do it manually, you might be doing it on RGB32 (full processing mode).

Or maybe I'm wrong.

Radek

[Sharktooth]

Revision 123 vfw: outdated

Changes:
(rev 121) VfW: x264_log now creates a window for error messages
(rev 122) In N-pass mode if stat_in and stat_out are the same file, instead save to a temp file and overwrite stat_in only when the encode finishes.
(rev 123) Cache half-pixel interpolated reference frames, to avoid duplicate motion compensation.
30-50% speedup at subq=5.

Notes: Build with gcc + nasm and default flags + NDEBUG=1.

[len0x]

Wow, that is indeed a nice speedup! I got more than 30% overall speedup in my tests. Well done, akupenguin! :)

[Doom9]

poor Sharktooth will have to restart his Nero AVC vs. x264 speed test ;)

[Lefungus]

Originally posted by len0x
Wow, that is indeed a nice speedup! I got more than 30% overall speedup in my tests. Well done, akupenguin! :)

Actually, it's the first core patch from syskin.
Everybody would have been satisfied with 10-15% speedup but he thought 30% was fine too :D

[sysKin]

Originally posted by Lefungus
Actually, it's the first core patch from syskin.
Everybody would have been satisfied with 10-15% speedup but he thought 30% was fine too :D Yeah I thought it would be ok ;) but just in case, another 2% with the first sex264 build in some time: http://syskin.is.dreaming.org/x264/ . Diff available.

Have fun,
Radek

[len0x]

Originally posted by Lefungus
Actually, it's the first core patch from syskin.


Kudos to him then :)

Originally posted by Lefungus
Everybody would have been satisfied with 10-15% speedup but he thought 30% was fine too :D

I hope its not as fast as it can get - I want more speedup :D

[igor1st]

Originally posted by sysKin
Just guessing, but:
- vdub 1.5 uses YUY2 (not sure) for its "fast recompress" colourspace.
- vdub 1.6 uses YV12
- when you do it manually, you might be doing it on RGB32 (full processing mode).

Or maybe I'm wrong.

Radek
Original VDub uses only YUY2 (in my tests). But VDubMod is able to use YV12.

[hpn]

Originally posted by len0x
Bitrate makes no difference for first pass stats files as you don't have this setting available during first pass, so it must be something else...

Correct. I'm only going to the second pass (for which I need to specify some bitrate of course) to be able to visually compare the 3 resulting encodes. I can't spot any difference by just watching the vids, but It's there when I make a few screenshots and put the corresponding frames side by side (one over another to be exact).

@sysKin: Thanks for the tip. It must really be connected to the way both versions handle colorspace. I just did 6 different encodes using, fast, normal and full recompress in both VDubs and ended up with 6 different first pass stats files. I'll also try to make some custom build GKnot replacing the 1.5.10 with 1.6.4 and run some more tests, plus some tests with MeGUI. I wouldn't be suprised if I get 10 different encodes at the end at the day, using one and only x264 set of settings :) So I still have to find out which one would be theoretically the best encode of all. Of course it's paranoic, cause all encodes are visually transparent.

[hpn]

Short speed test with the new sysKin 123 build:

Build 117 - 17:30 min. (1050sec.)
Build 123 - 14:59 min. (899sec.)

Edit: (Feb. 24) AthlonXP build 142 - 13:42 min. (822sec.)

14.38% overall speed boost for build 123.

4525 frames, two pass encode, default x264 advanced settings, plus fast first pass disabled, 700kbps

Always nice to see more developers in charge, only hope it won't lead to bunch of x264 branches and complete mess (still not a word at videolan.org x264 repository about any build 123, not that I'm familiar with how exactly these multi-developers projects should work)

EDIT:
Another test, this time at max quality settings (Max reference frames 15, Max B-Frames 1)

Build 117 - 31:02 min. (1862sec.)
Build 123 - 23:25 min. (1405sec.)

24.54% overall speed boost here, so I updated my humble comparison page at
http://www.freewebs.com/hdar/index4.html

[hellfred]

Originally posted by Doom9
poor Sharktooth will have to restart his Nero AVC vs. x264 speed test ;)
Did he already post results of full length encode? I was waiting for that. Did I miss it?

Hellfred

EDIT: OK, I had a look and just found a "Cooming soon" on page 23.

[Sharktooth]

Originally posted by Doom9
poor Sharktooth will have to restart his Nero AVC vs. x264 speed test ;)
... i know :(

@hellfred: no unfortunately i was a bit busy during last week, however at this point i think i will wait a bit to start the test.
New recode version is coming and syskin is on fire :D

[baer999]

wow thats amazing how the time was reduced ! Is there still a time reduce makeable ? That would be great !

[Sharktooth]

Revision 126 vfw is here: http://forum.doom9.org/showthread.php?s=&threadid=89979

I will keep updating that thread daily.

[niamh]

This is nice to have a special sticky for it..the pace this revs are coming out, it's even impossible to try them all :D

[Sharktooth]

i know...i re-started the same encode 5 times... :eek:

[Tommy Carrot]

Originally posted by Sharktooth
Revision 126 vfw is hereAnother nice speedup, almost 10% faster than rev. 123 (11:42 min vs. 12:48)! Well done guys!

Btw, it seems the optimizations on CABAC were very successful, now it's barely slower than CAVLC (~20 sec difference on the above mentioned clip).

[Sirber]

nice nice :D

[igor1st]

I am using a VFW version of x264. And I notice that with long-run encodes the size of file cache grows up and eats almost all free memory.
It can be fixed?

[bond]

Originally posted by igor1st
I am using a VFW version of x264. And I notice that with long-run encodes the size of file cache grows up and eats almost all free memory.
It can be fixed? how much space does it need?

[akupenguin]

Originally posted by Tommy Carrot
Btw, it seems the optimizations on CABAC were very successful, now it's barely slower than CAVLC (~20 sec difference on the above mentioned clip).
CABAC was not modified.

[virus]

Originally posted by igor1st
I am using a VFW version of x264. And I notice that with long-run encodes the size of file cache grows up and eats almost all free memory.
It can be fixed?
If you refer to the file cache, this is perfectly normal. Windows caches both the input and the output file as the encode progresses, using all the free memory available. That memory is freed when needed by other applications. Of course, the file cache is handled by the OS so x264 or any other program has nothing to do with it.

If instead, you refer to the application memory used by vdub(mod) when encoding, then no, it shouldn't grow so high during the encode, not even with latest sysKin's patch, which at 720x576 adds just 441 KB of RAM for each reference frame used.

[igor1st]

Originally posted by bond
how much space does it need?
Today size of file cache reachs ~320MB and amount of free memory decreases to ~30MB.

All my memory - 512MB; OS is XP with SP2; VirtualDubMod 1.5.10.1 build 2439.

[Tommy Carrot]

Originally posted by akupenguin
CABAC was not modified.
I know, but i didn't test the CABAC vs CAVLC performance since rev. ~50, and back then the difference was much bigger.

[igor1st]

Originally posted by virus
If you refer to the file cache, this is perfectly normal. Windows caches both the input and the output file as the encode progresses, using all the free memory available. That memory is freed when needed by other applications. Of course, the file cache is handled by the OS so x264 or any other program has nothing to do with it.

If instead, you refer to the application memory used by vdub(mod) when encoding, then no, it shouldn't grow so high during the encode, not even with latest sysKin's patch, which at 720x576 adds just 441 KB of RAM for each reference frame used.
Most likely that it's my own internal software problem.
A thousand apologies. :)

[peteag]

how's the x.264-codec comparable to the full-featured h.264-standard-codec? looking at the filesize of the codec (app 200kb) and the reference (app 900kb) some features might be missing or incomplete?

[akupenguin]

JM contains an encoder and a decoder, and they don't share any code (anything in common is duplicated). x264 is only an encoder.
x264 doesn't do any of extended profile or high profile. (Though "extended" is misleading, since it's all about error resilience, and is worse in compression ratio than main profile.)
Properly dealing with adaptive interlacing in all cases takes lots of code. x264 doesn't support interlacing.
There are a few other features not supported (weighted prediction, MMCO, B4x4, IPCM)
And the rest is different algorithms (RD aso)

... or we might just be more efficient.

[dragongodz]

or we might just be more efficient.
thats no doubt true. reference software is never really made for speed or efficienty. its simply made to produce the desired output. :)

[Yong]

What's problem with my x264 encoding options?
start /b /low /w avs2yuv %1 -o - | start /b /low /w mencoder - -noskip -nosound -o nul: -ovc x264 -x264encopts keyint=300:nocabac:nodeblock:no4x4mv:nob8x8mv:no8x8mv:subq=1:bframes=3:pass=1:qp_constant=18 -passlogfile "x264.log"

start /b /low /w avs2yuv %1 -o - | start /b /low /w mencoder - -nosound -noskip -o "%temp%\temp.264" -ovc x264 -x264encopts keyint=300: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:pass=2:bframes=3:bitrate=800 -passlogfile "x264.log" -ffourcc X264 -of rawvideo

I always get undersized(target bitrate is 800kbps, but result always is around 350kbps) file with some MPEG1 clips:(
I use virus' x264 r123 encoding pack ;)
The x264vfw doesn't have this kind of problem :)

[virus]

Originally posted by Yong
What's problem with my x264 encoding options?

I think you're going way too far with 1st pass reductions.

Leave cabac and inloop on for both passes, and use subq=3 for the 1stpass as well. And if you use 15 ref frames on the 2nd pass, you should use several ref frames on the 1st, too (VfW would use 8 in this case). I'm not surprised VfW works ok: "fast first pass" does a much better job of reducing the 1st pass complexity automatically ;)

If your clip is short and very complex, using 3 bvops (why 3? no more than 1 is recommended, and 0 is even better currently) may make the RC go off quite a bit. Use 3-pass to correct that.

Also you may check that the bitrate is not too high by looking at the average quantizers (use :log=2 to enable that). BTW I've already updated my pack twice since rev. 123 ;)

[pest]

i've tried several versions of x264 but virtualdub 1.6.4
freezes on the first 2nd-pass frame :(
1st pass and single-pass work as expected...nice speed :)

could be my crappy athlon-tb if no one else has
similiar problems

[Yong]

@virus:
Thanks for the advice, try it tonight:)

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

[azsd]

Hi,celtic_druid

follow your site's http://celticdruid.no-ip.com/xvid/
I click the mplayer/mencoder link and only get some mplayer binarary listed to feb 22

does I visited a wrong page?

[Neo Neko]

Originally posted by 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.

Sticky says ...... sherpya. ;)

Originally posted by azsd
Hi,celtic_druid

follow your site's http://celticdruid.no-ip.com/xvid/
I click the mplayer/mencoder link and only get some mplayer binarary listed to feb 22

does I visited a wrong page?

No you are basically on the right page. He is doing compiles. But apparently they are not getting mirrored. Cause 22nd is the last one I have seen there for a long time.

[Wolfor]

Is anybody developing the High (FRext) profile? And where can I find streams for testing decoder?

[bond]

Originally posted by Wolfor
Is anybody developing the High (FRext) profile? And where can I find streams for testing decoder? encode some yourself with the reference encoder

[Wolfor]

It's a bad way.. Because JM 9.3 is a very slow.. And I want to test alternative stream.
I have many questions about (JVT-L047d9) and (JVT-G050r1) documents..
May I asked? Or it's another subject.

[Doom9]

I have many questions about (JVT-L047d9) and (JVT-G050r1) documents..
May I asked? Or it's another subject.This line of questions doesn't fit the x264 thread (x264 is more or less a main profile AVC encoder)

[lithoc]

Does anyone try compile x264 using GCC 4.0 cvs?
I heard there's a lot of improvement made to this compier.
Anywhere I can get those binaries?

Thanks in advance

[baer999]

2 days without a new version of x264... I can't imagine this. What will be improved in the next versions ?

[Sirber]

Originally posted by lithoc
Does anyone try compile x264 using GCC 4.0 cvs?
I heard there's a lot of improvement made to this compier.
Anywhere I can get those binaries?

Thanks in advance What kind of improvements?

[ak]

From quicky test, gcc 4.0 tad slower and produces lower psnr (same cflags/encoding settings) than 3.4 series.

Here's some binaries (cli and vfw, r146): http://4nykey.nm.ru/misc/x264_gcc40.7z

[len0x]

Originally posted by baer999
2 days without a new version of x264...

Rev 146 is out for quite a while (not in the sticky thread though). Very nice speedup of the first pass :)

[lithoc]

Originally posted by Sirber
What kind of improvements?

According to changelog it says:

The tree ssa branch has been merged. This merge has brought in a completely new optimization framework based on a higher level intermediate representation than the existing RTL representation. Numerous new code transformations based on the new framework are available in GCC 4.0, including:

* Scalar replacement of aggregates
* Constant propagation
* Value range propagation
* Partial redundancy elimination
* Load and store motion
* Strength reduction
* Dead store elimination
* Dead and unreachable code elimination
* Autovectorization
* Loop interchange
* Tail recursion by accumulation

[lithoc]

Is there any way that I can obtain the latest build?
I've look around in variuos places, no sign of r146

Thanks

[Leo 69]

Yes I'm also anxious to get rev 146 build. Where is it? I need to recode some stuff tonight. Preferably with the cutting-edge encoder :)

[celtic_druid]

http://rapidshare.de/files/743270/X264VfW.revision146.exe.html

[niamh]

also check out the daily build thread, there's a good surprise in store :)

[Leo 69]

From the rev.145 changelog :

(fast1stpass was slower than non-fast)

They've fixed it, at last :D

[lithoc]

Got it
Thanks a lot!!!

[Sharktooth]

Sorry guys, i have no internet connection until the weekend... the reason is ... EXCESS OF SNOW (no, not the codec...).

[bond]

Originally posted by Sharktooth
Sorry guys, i have no internet connection until the weekend... the reason is ... EXCESS OF SNOW (no, not the codec...). cocaine? :p

[len0x]

Originally posted by bond
cocaine? :p

That would be blow :p

[thed33p]

(+5, Funny)

I've been lurking for a long while now.

LUV your work

(Hope to understand it eventually)

[lithoc]

Does anybody experiecing strange blocks in the video.
I'm experiencing some blocky B-frames with celtic_druid r146 build.

I usually encode with mencoder so I'm not sure if this is normal.



:confused:

[Sirber]

Something like this (http://forum.doom9.org/showthread.php?s=&threadid=90635)?

[Kurtnoise]

I've a question regarding the stats file (w/ r144 build). It looks like this :

in:5 out:6 type:B q:28.000 itex:127 ptex:379 mv:310 misc:288 imb:4 pmb:40 smb:640;
in:8 out:7 type:P q:26.000 itex:343 ptex:2908 mv:1356 misc:617 imb:17 pmb:184 smb:483;
in:7 out:8 type:B q:28.000 itex:163 ptex:531 mv:611 misc:479 imb:5 pmb:115 smb:564;
in:10 out:9 type:P q:26.000 itex:743 ptex:2616 mv:1272 misc:537 imb:24 pmb:131 smb:529;
in:9 out:10 type:B q:28.000 itex:309 ptex:944 mv:484 misc:407 imb:10 pmb:68 smb:606;
in:12 out:11 type:P q:26.000 itex:820 ptex:2487 mv:1283 misc:538 imb:25 pmb:132 smb:527;
in:11 out:12 type:B q:28.000 itex:510 ptex:752 mv:647 misc:451 imb:14 pmb:82 smb:588;
in:14 out:13 type:P q:26.000 itex:1186 ptex:2174 mv:1381 misc:619 imb:36 pmb:145 smb:503;
in:13 out:14 type:B q:28.000 itex:324 ptex:448 mv:629 misc:423 imb:10 pmb:84 smb:590;
in:16 out:15 type:P q:26.000 itex:426 ptex:2434 mv:1406 misc:526 imb:24 pmb:137 smb:523;
in:15 out:16 type:B q:28.000 itex:58 ptex:534 mv:328 misc:368 imb:4 pmb:58 smb:622;
in:18 out:17 type:P q:26.000 itex:535 ptex:1941 mv:1072 misc:476 imb:16 pmb:115 smb:553;
in:17 out:18 type:B q:28.000 itex:604 ptex:764 mv:599 misc:409 imb:16 pmb:70 smb:598;
in:20 out:19 type:P q:26.000 itex:923 ptex:2959 mv:1481 misc:565 imb:24 pmb:180 smb:480;
in:19 out:20 type:B q:28.000 itex:29 ptex:798 mv:565 misc:432 imb:2 pmb:103 smb:579;

What are exactly the itex, ptex and misc values ??

Thanks.

[Manao]

itex : texture size for intra macroblocks
ptex : texture size for inter macroblocks ( P + B )
mv : mv size for inter macroblocks ( P + B )
misc : header size for macroblocks
imb : intra macroblocks count
pmb : inter macroblocks count
smb : skip macroblocks count

texture size : size of the encoded DCT coefficients
mv size : size of the motion vectors, in bits ( not their actual length )
header size : macroblock size - texture size - mv size

[Kurtnoise]

10x Dude...;)

[Sharktooth]

I'm back on line... and my builds too.

[Tommy Carrot]

Sharktooth, the compiler bug is back in your latest build! This (http://www.fw.hu/carrotland/compilerbug.avi) is what i mean. If i remember correctly, the -O3 flag is the culprit.

[Sharktooth]

damnit, i reinstalled all the mingw stuff coz it was b0rked... now it's all ok but gcc has problems... argh... i hate it.
Anyone tested with 3.4.1.x? Does it show the same problem?

[len0x]

Originally posted by Tommy Carrot
Sharktooth, the compiler bug is back in your latest build! This (http://www.fw.hu/carrotland/compilerbug.avi) is what i mean. If i remember correctly, the -O3 flag is the culprit.

I've made a default complile of revision 149 with gcc 3.4.1.1 Can you check if the problem is still there? (core is still compiled with -O3). Get it here (http://len0x.leffe.dnsalias.com/x264vfw.zip)

[Sharktooth]

len0x can you try the -O3 switch in vfw too?

[len0x]

Here (http://len0x.leffe.dnsalias.com/x264vfw2.zip) is VFW compiled with -O3 (the rest is the same as my previous compile).

[Sharktooth]

OK, like i said in the other thread it's the -fomit-frame-pointer flag that should be avoided.
I dont know why but it is causing the effect you can see in the tommy carrot's sample.
Tested with gcc 3.4.2.

[hpn]

Seems lots of code has been added or changed in rev.150 dealing with b-frames, so I just tested the new Sharktooth's build with 3 b-frames (plus 8 ref. frames) and the encode looks smooth as silk without any artifacts, like blocking etc. I think 3 b-frames will be my way to encode from now on. However I noticed that there was no upper limit to the max b-frames number, so I tested with some insanely high numbers, like 50 or 100, just to see what would happen (I guess some code should be added to prevent people from doing this). The encoding starts but at about 60% of the first pass an "x264 error console" pops up, stating "specified frame type is not compatible with max b-frames" then VirtualDub keeps encoding and at the end of the first pass (99%) crashes and exits.

edit: also the x264-1.stats contains only I and P frames, so b-frames seems disabled in case of invalid max b-frames number

edit2: Couldn't find any "B-frame pyramid" option mentioned in the SVN to play with. Isn't it something that should be available in the user interface or it's only some "internal" encoder stuff?

[celtic_druid]

Max bframes is set to 16 in mencoder.

B-frame pyramid is enabled in the last mencoder build that I did. Use b_pyramid=1 to enable.

Also I did a rev151 build with it enabled in the VFW, don't think that has been mirrored though. Untill ffdshow gets updated you would need mplayer to play it anyway.

[hpn]

Originally posted by celtic_druid
Max bframes is set to 16 in mencoder.
Actually the max B-frames number that works in my VFW tests is 15. For 16 (or more) the encoding crashes during the first pass and the stat files contains only I and P frames.

By the way, is it a good idea to use 15 max b-frames for an average movie encode? For example Nero "Max definition - AVC" profile only allows 4 max b-frames and 3 for the other profiles. But when I examine a 15 b-frames x264 encode I can spot that some "complete dark" scenes really use 15 bframes, like pbbbbbbbbbbbbbbb-pbbbbbbbbbbbbbbb-pbbbbbbbbbbbbbbb..., which I guess delivers better compression than 3 bframes (pbbb-pbbb-pbbb..). Even if I set 15 b-frames 99% of the movie still uses no more than 4 consecutive bf, so seems it's pretty safe to put 15 and give the encoder the freedom to decide (especially if fenrir keeps tweaking the b-frames placement)

[akupenguin]

With CABAC, pure black frames will be compressed to nothing no matter whether they're P or B. Even if 15 B-frames doesn't crash, I wouldn't call it safe, as I've only just started testing more than 3. That said, one of the eventual goals of a B-frame placement algo is that increasing max B-frames should never hurt compression.

And it's sysKin and I that are tweaking B-frame placement. The last time fenrir touched x264 code was before B-frames were usable.

[hpn]

Originally posted by akupenguin
And it's sysKin and I that are tweaking B-frame placement.
My bad, sorry. Just a lapse of the tongue :D, cause I read some thread about fenrir a few hours ago. Keep up the good work.

[virus]

Originally posted by hpn
The encoding starts but at about 60% of the first pass an "x264 error console" pops up, stating "specified frame type is not compatible with max b-frames"
:)

Finally that code proves to be useful. Usually the error window surprises (scares?) the user, who doesn't expect such a feature. There's even a button that allows to copy the content of the window to the clipboard. All a n00b can ever need :D

[Sharktooth]

Originally posted by celtic_druid
Also I did a rev151 build with it enabled in the VFW, don't think that has been mirrored though. Untill ffdshow gets updated you would need mplayer to play it anyway.
Mirroring both 151 and 152 and avc2avi.

@akupenguin: Can you please add a checkbox for enabling/disabling B-Frames Pyramid in vfw too?

[MacAddict]

Amazing development speed! Just a big thanks to all those who are involved coding, testing, compiling, mirroring, etc.

[akupenguin]

Originally posted by Sharktooth
@akupenguin: Can you please add a checkbox for enabling/disabling B-Frames Pyramid in vfw too?
No, I don't do win32 guis. Bug virus or someone.

[Sharktooth]

Ok, celtic druid made a couple of patches for that, it also uncomments the Configure from the def's file and It also includes some crap that MSVC changed I think isn't really needed.

The diffs are here: http://www.aziendeassociate.it/cd/x264/pyramid.diff
and here: http://www.aziendeassociate.it/cd/x264/pyramid2.diff

Also there are some more parameters in CLI encoder that IMHO should be also added in the vfw interface:
--b-bias parameter (Influences how often B-frames are used)
--weightb (Weighted prediction for B-frames)
--sar (Specify Sample Aspect Ratio)

[bob0r]

[off topic but useful]
If any people want a *.x264.nl subdomain pointed to their static ip, just drop me a PM or an email sub@x264.nl.
Just for easy remembering and we can make a list of subdomains for x264 related info/downloads.
Could be handy for custom builds and other tests/experiments or what ever x264 related things you can think up!
[/off topic but useful]

I too must say x264 development is going great and i'll do my best to support x264 in the ways i can.

Carry on! :D

[unmei]

Can someone briefly explain what this B-frame pyramid is/does?
And what effect it could have when played in "non-ready" FFDShow?

I encoded a OVA using the non-patched rev 153 vfw today, but so far it seems to play without problems using the FFDShow from march 3..

[BoNz1]

Originally posted by unmei
Can someone briefly explain what this B-frame pyramid is/does?
And what effect it could have when played in "non-ready" FFDShow?

I encoded a OVA using the non-patched rev 153 vfw today, but so far it seems to play without problems using the FFDShow from march 3..

The bframe pyramid allows bframes to reference each other and because of this, some frame reordering must occur. If you encode with the bframe pyramid on, it will not play in the latest ffdshow. Likely it will stall after a couple frames. You will need to update libavcodec from ffmpeg and build a new ffdshow. The vanilla rev153 from the svn does not have bframe pyramids enabled by default so it will play correctly. BTW does anyone have a newer ffdshow than march 3?

[unmei]

OK, thanks a lot for the quick reply. So i better do not turn it on now :)

[celtic_druid]

Yes, don't turn it on if you want it to playback with current ffdshow. However ffdshow should support it in the future and mplayer supports it right now.

libavcodec hasn't been updated in the cvs so no real point in a new build. Also updating libavcodec in ffdshow is not that simple, the updates need to be modifed to work.

weightb currently gets enabled by default if bframes > 1.
b-bias I guess could be usefull, not so sure about sar.

[Tommy Carrot]

I'm curious, if a b-frame can be used as reference for other frames, the higher quantization of the reference b-frame wont hurt the overall quality? One of the advantage of the b-frame is that you can safely compress it more because it's not used as reference, hence it doesn't influence the quality of other frames. But this will change with pyramid b-frames. Could someone explain me how can x264 avoid this problem?

[Manao]

By making the quantizer of bref lower than non-references bframes.

Moreover, bframes aren't only efficient because they allow to raise the quantizer : a clip with b & p at same quantizers will have a higher PSNR than a clip without bframes.

That allows bref, even if they are less quantized than 'normal' bframes, to raise yet again the quality.

[Tommy Carrot]

Thanks, that's what i thought too. :)

[sysKin]

Originally posted by Tommy Carrot
I'm curious, if a b-frame can be used as reference for other frames, the higher quantization of the reference b-frame wont hurt the overall quality? One of the advantage of the b-frame is that you can safely compress it more because it's not used as reference, hence it doesn't influence the quality of other frames. But this will change with pyramid b-frames. Could someone explain me how can x264 avoid this problem? Because AVC allows multiple references in every direction, any block has a choice, whether to motion compensate from closer (but possibly lower quality) picture, or from further away, but lower quant, pframe. So it's simply about extra choice :)

Radek

[Koti]

If you encode with the bframe pyramid on, it will not play in the latest ffdshow. Likely it will stall after a couple frames.

Hehe, Yep ffdshow stall - crash , but nero's avc decoder works with b frame pyramid.

[TheUnforgiven]

Great work
but could somebody add a status window or at least a simple debug output to the vfw version.
i hate to encode blindly!

[celtic_druid]

Someone want to test this? http://celticdruid.no-ip.com/test/libavcodec.bpyramid.7z

patched libavcodec for ffdshow. Works ok decoding bframe pyramid encodes here. Although I didn't test much.

[Yong]

Here's the info from mailing list:
r152 | pengvado | 2005-03-05 05:16:05 +0100 (Sat, 05 Mar 2005) | 2
lines
Changed paths:
M /trunk/common/common.h
M /trunk/encoder/encoder.c
M /trunk/encoder/ratecontrol.c
M /trunk/vfw/config.c

allow 16 refs (instead of 15)

--
This is the x264-devel mailing-list
I tried with mencoder with frameref=16, but mencoder still complaining frameref>16 and stop the encoding job...:(
EDIT: i use x264r153 and mplayer daily CVS build.

[Teegedeck]

Originally posted by celtic_druid
Someone want to test this? http://celticdruid.no-ip.com/test/libavcodec.bpyramid.7z

patched libavcodec for ffdshow. Works ok decoding bframe pyramid encodes here. Although I didn't test much.
It works flawlessly, even on a clip with max. 10 ref. frames and max-idr=500. Thanks a lot!

[akupenguin]

Originally posted by Yong
I tried with mencoder with frameref=16, but mencoder still complaining frameref>16 and stop the encoding job... I haven't patched mencoder to loosen that restriction, since 15 B-frames is overkill too. This is just to prevent a crash found by Spyder, who is writing his own frontend.

[Yong]

Originally posted by akupenguin
I haven't patched mencoder to loosen that restriction, since 15 B-frames is overkill too. This is just to prevent a crash found by Spyder, who is writing his own frontend.
I haven't test with b-frames=16,
but what i say is frameref=16:)

[Sharktooth]

Can someone please test my latest build (rev156) with the celtic druid's patch?

[mezzanine]

Originally posted by Sharktooth
Can someone please test my latest build (rev156) with the celtic druid's patch?

Just did, works fine.

[Sharktooth]

good ;)

[scorpdt]

Works fine on my end too.

[celtic_druid]

If you want 16 ref frames then you need to change ve_x264.c max ref value from 15 to 16 which I did in my last mencoder compile anyway.

About the VfW GUI. I shifted some stuff round. Anyone got any comments/advice on that? Just thought that with the two new bframes settings added it should have its own section.

[Chainmax]

I have a couple of questions that are probably extremely n00bish, so please bear with me. From what I read all this time, AVC used to have blocking issues on bframes and that was due to lack of deblicking on the decoding end. Will postprocessing be always necessary? I never play my Xvid encodes with postprocessing, and I'd like to do the same with future AVC encodes, will that be possible? Also, is there any chance that x264 can output .mp4 files since AVC in AVI is such a bad idea according to the FAQ?

[Doom9]

Also, is there any chance that x264 can output .mp4 files since AVC in AVI is such a bad idea according to the FAQ?Please have a look at the x264 sticky: http://forum.doom9.org/showthread.php?s=&threadid=89979

There you can find a quote from yours truly that applies here: x264 is encoding application agnostic. The output format is encoding application dependant, not codec dependant. VDub and every other VfW based tool will give you video in the AVI container. mencoder, can also give it to your RAW. ffmpeg can output to MP4, but that feature is kinda broken, and currently x264 is not integrated into ffmpeg. So, there is no application that can encode using the x264 codec and put the video data into the MP4 container. You'll need to either create a raw output and mux that into MP4 using a tool like mp4creator, or make an AVI, extract the AVC video using avi2raw, then mux the raw data into MP4. The first approach is used by MeGUI (http://forum.doom9.org/showthread.php?s=&threadid=87567), the 2nd by AutoAC (http://forum.doom9.org/showthread.php?s=&threadid=90732) and mp4muxer (http://forum.doom9.org/showthread.php?s=&threadid=89803). Now the choice is yours.

Note that even though mp4creator supports AVI input, it cannot handle the tricks used to get B-frames into AVI, so don't use mp4creator with AVI input.. always go via RAW. The tools mentioned above will do that automatically for you.

[Tommy Carrot]

Originally posted by Chainmax
I have a couple of questions that are probably extremely n00bish, so please bear with me. From what I read all this time, AVC used to have blocking issues on bframes and that was due to lack of deblicking on the decoding end. Will postprocessing be always necessary? I never play my Xvid encodes with postprocessing, and I'd like to do the same with future AVC encodes, will that be possible? Unfortunately the blocking in h.264 is much more visible and annoying than in ASP, so deblocking is necessary. The best you can do is to weaken the deblocking as far as you can while the image is still relatively clean, but completely disabling the loop-filter is not a good idea imo. Akupenguin hinted though that high profile may bring an improvement in this field.

[Doom9]

Unfortunately the blocking in h.264 is much more visible and annoying than in ASP, so deblocking is necessary. The best you can do is to weaken the deblocking as far as you can while the image is still relatively clean, but completely disabling the loop-filter is not a good idea imo. Should that even be possible? I thought the in-loop filter was a given for AVC. And to the best of my knowledge, neither Nero AVC nor VSSH actually has postprocessing in their decoder (I know for sure for Nero), but I figure the in-loop filter is still active because they don't have any issues with B-frames, even in the absence of dedicated postprocessing in the sense we know it from MPEG-4 ASP codecs.

And, I only have limited experience with x264 in that area, but when I disabled postprocessing in ffdshow, the movie I watched looked much more visually pleasing.. postprocessing introduced a lot of visible artifacts. So I guess I should watch that same movie using the Nero filters to check for a difference.. and it would probably also be interesting to see how the Nero filters do playing contents where ffdshow has/had those blocking issues.

[netchris]

Nero decoder should be more complete compatibility wise, though i dont have any problems decoding my nero-avc encodes with ffdshow.
Its true that even minimal ffdshow postprocessing only harms the picture. Besides postprocessing aint needed in avc (thanks to inloop magic).

[akupenguin]

Originally posted by Chainmax
From what I read all this time, AVC used to have blocking issues on bframes and that was due to lack of deblicking on the decoding end. Will postprocessing be always necessary?
The deblocking that was lacking in ffdshow was in-loop filtering, not postprocessing. It is not a decoder choice; any decoder that doesn't perform deblocking (when specified by the encoder) is not standards compliant.

At this time, there are no known postprocessors for H.264, and using a postprocessor designed for ASP will only reduce the video quality.

[hpn]

Just tested the ST's rev.157. The so called "B pyramid" is now officially available in the VFW under the "Use as a reference" option (correct me if I'm wrong). Max b-frames is limited to 5, hopefully temporarily until the bframes code gets tweaked in the future (more b-frames always sounds tempting). For now to enable "Use as a reference" is a bad idea cause ffdshow is still unable to play such encodes (hopefully also fixed soon). MPlayer playes such encodes fine, as long as you use less than 15 ref. frames. For 15 and 16 refs and "Use as a reference" option enabled, Mplayer crashes stating: "MPlayer interrupted by signal 11 in module: decode_video, - MPlayer crashed by bad usage of CPU/FPU/RAM." I have no idea if it's a bug in the encoder or Mplayer (same bug with the patched 156 yesterday). And finally I still wonder what was the reason for upping the Max ref. frames from 15 to only 16 (why not to 24 for example). Either 15 or 16 is overkill anyway, so I don't get it. I guess theoretically we don't have an upper limit for ref. frames, as long as the encoding time remains reasonably low and real time playback of the resulting encode can be achieved.

[akupenguin]

16 is the max allowed by the H.264 standard. It was previously limited to 15 because 16 crashed the encoder.

[hpn]

That explains everything, thank you, akupenguin. Just keep up the nice work.
(I wouldn't be surprised if the "Moving Picture Experts Group" guys are already secretely working on some next gen. standard)

[Doom9]

The deblocking that was lacking in ffdshow was in-loop filtering, not postprocessing. It is not a decoder choice; any decoder that doesn't perform deblocking (when specified by the encoder) is not standards compliant.Thanks for the confirmation. So, until recently ffdshow's AVC decoder was not specs compliant and hence the b-frame quality problems.

and using a postprocessor designed for ASP will only reduce the video quality.I can absolutely confirm that, so make sure you disabled postprocessing in ffdshow when watching x264, or other AVC content. I guess it would be nice if that were done automatically considering that having it turned on only harms the output.

[JimiK]

First, also from me a big thanks to all people involved in this project!
Should referring frames look better when B-Frames are also used as reference?
It does not seem to decrease filesize. At least in my (short) test the size increased always by a very slight amount when B-Frames were used as reference.
In the mplayer manpages also stood that it would introduce an additional delay of 2 frames (maybe of #max_bframes frames?). I couldn't check this with mp4, because VDubMod as my editing program can only open avi. With Avi there are #max_bframes as dummy frames insertet, no matter if B-Frames are used as reference or not.

[stephanV]

AFAIK b-refs should not necessarily introduce an additional delay when b-frames were already used.

How useful b-refs will be still has to be seen. For anime it seems to work, for real content it is not sure.

[Sagittaire]

VFWx264 rev 157 (celtic_druid)

With ffdshow or ateme dec
defaut + 16 refs: bug for player (MPC)
defaut + 15 refs: no bug
defaut + bframe ref: bug for player (MPC)

with Nero AVC dec:
defaut + 16 refs + bframe ref: no bug but very high CPU level for player (MPC)

[Sharktooth]

@sagittaire: What decoder you use?

[Sagittaire]

VFWx264 rev 157 (celtic_druid)

With ffdshow or ateme dec
defaut + 16 refs: bug for player (MPC)
defaut + 15 refs: no bug
defaut + bframe ref: bug for player (MPC)

with Nero AVC dec:
defaut + 16 refs + bframe ref: no bug but very high CPU level for player (MPC). Video fluidity is worst.

[bond]

Originally posted by stephanV
[B]AFAIK b-refs should not necessarily introduce an additional delay when b-frames were already usedi dunno in what way b-frames as references makes arbitrary frame orders necessary, but with .avi you get one additional delay caused by the reordering (as done by x264 atm), which .avi isnt really capable to handle

of course with better containers, like .mkv and .mp4, which are able to handle arbitrary frame orders explicitely, this shouldnt happen

[Tommy Carrot]

But even with avi, it shouldn't introduce more delay. If the delay is equal to the maximum consecutive b-frame number, all of them are already buffered, so the order of them shouldn't matter.

[bond]

(23:35:02) (@pengvado) bond: avi doesn't support arbitrary frame orders any more or less than it has always supported unpacked B-frames.
(23:35:34) (bond) yep, but in practice it seems to work!?
(23:35:40) (@pengvado) the only thing wrong with AVC-in-AVI is timestamps / A-V sync.
(23:35:59) (@pengvado) the codec has sufficient info to reorder the frames for output
(23:36:32) (bond) hm can you explain how this works now using arbitrary orders with x264 in .avi?
(23:36:34) (@pengvado) however, since the only things that AVI does are seking and A-V sync, losing half of that does make it "broken" for all I care
(23:38:09) (@pengvado) x264 creates an elementary stream and hands it to mencoder. mencoder adds AVI headers and writes it to a file. mplayer reads the file, throws away the AVI headers, and gives the elementary stream to libavcodec. libavcodec reorders frames based on H.264 headers, and outputs in the correct order with undefined timestamps.
(23:38:45) (bond) hm and how would the reordering work out in practice, eg if decoding in vfw
(23:39:00) (bond) i mean with that 1 frame in/1 frame out limit
(23:39:23) (@pengvado) the first frame is output 3 times, the last 2 frames are dropped, and you get a 80ms A-V desync.
(23:39:38) (bond) ah so simply a bigger delay?
(23:39:58) (@pengvado) yes

[Tommy Carrot]

Akupenguin obviously knows a lot more about this stuff than me, but i still don't get it why should a bigger delay be necessary?

The delay is caused by a buffer to reorder the frames, because a reference frame must be placed before the frames which are using it as reference. let's see an example with 3 bframes:I b b b P
1 2 3 4 5 ; frames in original order
You have to reorder it to:I P b b b
1 5 2 3 4 ; after the reorderingYou need to buffer 3 frames, because the P-frame moves 3 frames away from its original place.

With bref this will be:I b B b P ; B is the b-frame which is used as reference
1 2 3 4 5This is stored like this:I P B b b
1 5 3 2 4As you see, you still only need to buffer 3 frames, i don't see the reason of the additional delay.

[Sagittaire]

hmm ... x264 in mp4 or mkv container don't work very well with multiref + bref ...

Perhabs muxing process:
avi2raw.exe -v x264-447.avi clip.h264
mp4creator.exe -c clip.h264 -rate 25 clip.mp4

if I use remux ateme exe result is the same: video playback is not very good with multiref + bref

[bond]

Originally posted by Sagittaire
hmm ... x264 in mp4 or mkv container don't work very well with multiref + bref ...i get this too when using bref (not with mref alone). i think thats caused by ffdshow. try the nero decoder, wait for ffdshow to be officially updated by milan to the latest ffmpeg sources or use latest mplayer

[stephanV]

Tommy Carrot: thats what i thought too :)

for 2 cons b-frames with b-ref it might be necessary though... IIRC the frame sequence will always be like this then:

1 2 3 4
I b B P

1 4 3 2
I P B b

thus three frames delay needed...

[Sharktooth]

I had some spare time this evening so i added some CPU optimized builds back to the x264 daily builds thread.
If you have some request for a particular version (SSE3?) just ask, i have still a couple of free hours.

[Sagittaire]

x264 and variability:


|---------------|---------|---------|
| Variability | OPSNR | SSIM |
|---------------|---------|---------|
| 000% | 39.3871 | 64.05 |
| 010% | 39.6695 | 65.23 |
| 020% | 39.9377 | 66.31 |
| 030% | 40.1266 | 67.08 |
| 040% | 40.2793 | 67.70 |
| 050% | 40.3925 | 68.19 |
| 060% | 40.4644 | 68.50 |
| 070% | 40.5003 | 68.66 |
| 080% | 40.4851 | 68.63 |
| 090% | 40.4357 | 68.51 |
| 100% | 40.3381 | 68.13 |
|---------------|---------|---------|


Optimal setting for this source and this quant is 75%. Optimal variability is perhabs not constant (change perhabs with source and average quant level) ...

[Sharktooth]

Uhm, what source?

[virus]

Originally posted by Sagittaire
x264 and variability
This is quite consistent with my own tests. If you want to optimize for Average PSNR, something around 40-50% should be good. If instead you want to optimize for Overall PSNR, you need to have a more "constant quantizer" behaviour, and so high values of variability are needed (70-90%).

The actual default (60%) should instead be a good starting point to find the maximum visual quality... but since visual quality is totally subjective (and things change when you change source and/or bitrate), that 60% is really just an hint. If some consensus can be reached on a different default which "looks better" on a wide range of sources we may ask akupenguin to change it. Rememeber that akupenguin tests on anime, so I'd suggest to investigate natural material... ;)

virus

[Tommy Carrot]

Originally posted by stephanV
Tommy Carrot: thats what i thought too :)

for 2 cons b-frames with b-ref it might be necessary though... IIRC the frame sequence will always be like this then:

1 2 3 4
I b B P

1 4 3 2
I P B b

thus three frames delay needed... Why? No matter how i see this, 2 frames delay should be enough in this case. And i know this doesn't matter here, as this is a purely theoretical discussion but doesn't x264 only uses b-ref with 3 or more consecutive b-frames?

Anyway, the question is still: why should b-ref introduce more delay?

[DeathTheSheep]

16 is the max allowed by the H.264 standard. It was previously limited to 15 because 16 crashed the encoder.

Really?!! I used more than 30 reference frames with revision 144 (or 139, I forgot) and it worked perfectly. There was a small file decrease over using 15.

I never experianced a crash until I tried to use 1000 (just for a test), and only then after the encode was nearly half finished. I think its limited to the amont of ram available, but by god i'm not sure and I know nothing.

Strange, though, how it actually did work for me. And yes, pyramiding does crash ffdshow.

Sheers. I mean, Cheers, y'all. Baa

[Sirber]

16 has always been working for me :confused:

[Manao]

Really?!! I used more than 30 reference frames with revision 144 (or 139, I forgot) and it worked perfectly. There was a small file decrease over using 15.Lol, amazing considering that the norm doesn't allow more than 16 references, and that x264 didn't allow more than 15 references before rev 152.

Moreover, and for the nth time, you won't notice any improvements with more than 5 references, and in fact, more than 2 references is often plainly useless considering the slowdown it creates.

[akupenguin]

Originally posted by Sirber
16 has always been working for me :confused: As with many of the options, if you select an invalid value, x264 clips it into the valid range. So your encode actually only used 15 refs.

Anyway, I increased the max not because 16 makes any difference, but because the limatation to 15 was caused by a bug.

[DeathTheSheep]

I've just looked back on an older version of x264 Revision 94. It seems to have a better compression ratio than the current one, and its .dll is much larger. Why is this? Seriously, with q=26 and similar options in both, the older version compressed better. Is this just because I'm doing something wrong (as usual?)?
Also wierd.



Yeah, and that reference thing... makes sense now that you mention the automatic value truncation, but that didn't work in older ones, I don't think, because there actually was a crash with 1000 and the filesize was a bit less than when I had used 15. Very, very strange. Want a file sample? (If i had somewhere to upload)

And Moreover, and for the nth time, you won't notice any improvements with more than 5 references, and in fact, more than 2 references is often plainly useless considering the slowdown it creates.

Yes, I totally agree. I was just doing it for testing purposes. ;-)

[Sagittaire]

Originally posted by virus
This is quite consistent with my own tests. If you want to optimize for Average PSNR, something around 40-50% should be good. If instead you want to optimize for Overall PSNR, you need to have a more "constant quantizer" behaviour, and so high values of variability are needed (70-90%).

The actual default (60%) should instead be a good starting point to find the maximum visual quality... but since visual quality is totally subjective (and things change when you change source and/or bitrate), that 60% is really just an hint. If some consensus can be reached on a different default which "looks better" on a wide range of sources we may ask akupenguin to change it. Rememeber that akupenguin tests on anime, so I'd suggest to investigate natural material... ;)

virus

best visual quality is subjective but for [60%-90%] interval variability metric is in practice constant : 60% for default setting is a good value for metric too ...

@DeathTheSheep
q24 for previous version is not equivalent at q24 for current version. Probaly RD setting, bframe ratio, bframe sensivity or other ...

q2 size for DivX and q2 size for XviD are very different with exactly the same setting but DivX and XviD obtain near result with same bitrate and with very different average quant ...

[DeathTheSheep]

True. I see. So does the compression quality subtly increase after each revision? Or are the absolute only changes limited strictly to what is written in the log?

[akupenguin]

Encoding delay is equal to the max consecutive B-frames. Decoding delay is 1 when traditional B-frames are used, and 2 when B-pyramid is used.

Note that only 1 delay is needed in order to ensure that each decoded frame is available in time for output:I b b b P
1 2 3 4 5 ; input order

I P b b b
1 5 2 3 4 ; coded order
- 1 2 3 4 5 ; display order

With B-pyramid, you need 2 delay to make sure frame#2 is decoded in time:I b B b P
1 2 3 4 5 ; input order

I P B b b ; coded order
1 5 3 2 4
- - 1 2 3 4 5 ; display order

Either way, decoding delay is independent of max B-frames:I b b b B b b b P
1 2 3 4 5 6 7 8 9 ; input order

I P B b b b b b b ; coded order
1 9 5 2 3 4 6 7 8
- - 1 2 3 4 5 6 7 8 9 ; display order

But note that the current B-pyramid is not the only way to use B-refs. Not all strategies require extra reordering, and some require more than 2 decoding delay and/or extra encoding delay. The following (not used by x264) requires 3 delay:I b B b B b B b P
1 2 3 4 5 6 7 8 9 ; input order

I P B B b b B b b ; coded order
1 9 5 3 2 4 7 6 8
- - - 1 2 3 4 5 6 7 8 9 ; display order

Of course, when I speak of delay, it only means delay between when you give a coded frame to the codec and when it returns the result. If the demuxer provides correct timestamps, the player can always decode enough frames in advance that the user won't see any delay.

[Tommy Carrot]

Thanks for the clarification, i was thinking only about the encoding delay. :)

[Capirossi]

nice codec :cool:

[lithoc]

Since rev150, I can't playback anymore.
It only playback for less tha a second then it crashed.

mplayer says:
[h264 @ 008E8E08]reference picture missing during reorder

Disregard if this issues have been identified.

Thanks for the great codec, now just hope it's compatible with hd-dvd/avc hardware player when it release

:)

[Sharktooth]

Try updating mplayer...

[lithoc]

Originally posted by Sharktooth
Try updating mplayer...

I'm using mplayer dated 5th March from http://oss.netfarm.it/mplayer-win32.php

Problem still exist

[Chainmax]

Originally posted by Doom9
there is no application that can encode using the x264 codec and put the video data into the MP4 container. You'll need to either create a raw output and mux that into MP4 using a tool like mp4creator, or make an AVI, extract the AVC video using avi2raw, then mux the raw data into MP4.

I understand, but the FAQ says that AVC in AVI doesn't allow implementation of some AVC features. What I don't fully understand is wether these limitations can appear at the encoding level (thus creating "broken" encodes) or just at the decoding level (so just using your suggestions would solve the problem.


I also have another question: I see that the H.264 specs include RDO and my question is wether H.264's RDO is identical to Xvid's VHQ or if there can be different approaches to RDO. Also, can Trellis be implemented in x264 or am I just talking nonsense?

[akupenguin]

Originally posted by Chainmax
I understand, but the FAQ says that AVC in AVI doesn't allow implementation of some AVC features. What I don't fully understand is wether these limitations can appear at the encoding level (thus creating "broken" encodes) or just at the decoding level (so just using your suggestions would solve the problem.
It's on the decoding end. You can always demux H.264 from AVI, and the result is the same as if you put it in a different container to begin with.

I also have another question: I see that the H.264 specs include RDO and my question is wether H.264's RDO is identical to Xvid's VHQ or if there can be different approaches to RDO. Also, can Trellis be implemented in x264 or am I just talking nonsense?
No, the H.264 specs do not contain RDO. RDO is not something that can be specified in a standard. It's an encoding technique, and it could be applied to any lossy codec you've ever heard of. However, the H.264 format is very different from ASP, so fast RDO requires different tricks.
Trellis does not really apply to CABAC, and trellis for CAVLC is harder that for ASP.

[Chainmax]

Got it. I misread the FAQ when it said "RDO is not a tool defined by the AVC/H.264 specs....was first introduced by the H.264 reference software". Anyway, I don't know how hard would it be to implement VHQ in H.264, but what about leaving it as an option like in Xvid?

[stephanV]

that RDO comment is inappropriate there in the sticky... its confusing...

[RadicalEd]

x264 encoding support has just been patched into FFMPEG.

[Sharktooth]

New Pentium2 build available (no SSE) in the daily builds thread. I also added an Athlon Thunderbird build (no SSE).
Both use -ffast-math so please test them and report back if they crashes.

EDIT: P4 Prescott with SSE3 support build is also available.

[ivan_alias]

Originally posted by RadicalEd
x264 encoding support has just been patched into FFMPEG.

This is good news isn't it!

[springl]

x264 compilation by sharktooth, bobor, CD
From rev 144 on, I'm getting garbage a few frames after last I frame, with this settings:
default + update statsfile unchecked + max consecutive B-frames 1 + max reference frames 15 + deblocking unchecked.
Same settings + max reference frames 1 seems to be OK.
Here Athlon Thunderbird CPU + win98SE OS

Greetings
Springl

[IgorC]

rev164 doesn´t work full recompress in Virtual Dub. Only fast

[unmei]

this line from the changelog in the sticky should explain it:

(r164) VfW: reject YUY2 and RGB input formats

[planet1]

Originally posted by IgorC
rev164 doesn´t work full recompress in Virtual Dub. Only fast

from what I see there are two options (if source is not @ yv12):

either convert to yv12 via avisynth first,

or use Virtualdub 1.6.4 which has more colour depth options (setting output to YV12)

---> all recompression modes should work with x264 now

[dragongodz]

either convert to yv12 via avisynth first,
or use Virtualdub 1.6.4 which has more colour depth options (setting output to YV12)
and if you are using a different program ,not avisynth or virtualdub, that doesnt output yv12 ?

so what was the thinking behind making x264 only accept yv12 anyway ? seems a strange idea since most codecs accept multiple inputs.

[Ark]

Probably because x264 can't (yet i suppose) do RGB/YUY2/whatever to YV12 internal conversion.

[celtic_druid]

Revision 166:
revert 164. blame Spyder.

and for reference...
Revision 164:
VfW: reject YUY2 and RGB input formats

[dragongodz]

Probably because x264 can't (yet i suppose) do RGB/YUY2/whatever to YV12 internal conversion.
well thats strange since i just did a little test using RGB24 to x264 revision 150 and it not only encoded fine but played back fine with ffdshow(using libavcodec) fine aswell.

also how were people using earlier than 1.64 virtualdub versions and encoding fine ?

[EDIT]
revert 164. blame Spyder.
ahh so it should be back to accepting RGB and YUY2 then. cool.

[Sharktooth]

rev. 170 up.

[hpn]

Sharktooth, does your generic 170 build take advantage of the SSE optimization introduced the latest rev.170, or "generic" in this case means that there will be no speed improvement over 169? (I guess "SSE optimized chroma MC" in r170 means speed optimization only, but I maybe wrong). I don't know much about these CPU things, but always looking for the best build for my Atlhon XP that has SSE support. I also have no idea how celtic druid or bob0r compile their latest stuff (most likely generic too).

[Sharktooth]

I've compiled a SSE build too. Check it out.

[hpn]

Thanks!:)

[planet1]

Originally posted by dragongodz


also how were people using earlier than 1.64 virtualdub versions and encoding fine ?


its a VirtualDub 1.6.x glitch (1.5.x has a different colour handling) and also affects XviD & DivX:

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

[dragongodz]

virtualdub works in RGB in full processing mode, which is default so most people would actually be using it.

if you read above however you will see x264 does accept RGB and it has already been fixed back to being accepted.

[Yong]

Is the b_pyramid enable by default in x264vfw?
i got crashed decoding with ffdshow or mplayer if encode video using x264vfw...
The patch (libavcodec.bpyramid.7z)by Celtic druid doesn't work for me, strange.:(
BTW my own compile x264.exe cannot run,
when i execute it, i got "something entry point not found" then it closed.
(sorry, can't remember the message...)

[Sergejack]

I got a recurrent bug with the 170 rlz.

the ecnode just screw a part, then the vidéo get desync.

[Yong]

After reading the mplayer man page, b_pyramid=use b-frames as reference frame:rolleyes:
Why the name in vfw isn't same as mencoder?
It's make newbies confusing:(
After turn it off everything went fine:D

Here's the error message went i execute the x264vfw:
x264.exe - Entry point not found
The procedure entry point AVIFileExit cound not be located in the Dynamic link library MSVFW.DLL
What's wrong with it?
previous revision doesn't have this problem.

X264 development is very fast, now already r174, great:)

[virus]

Originally posted by Yong
After reading the mplayer man page, b_pyramid=use b-frames as reference frame:rolleyes:
Why the name in vfw isn't same as mencoder?
It's make newbies confusing:(
This is a deliberate choice.
Keep in mind that most n00bs out there approach the codec for the first time through VfW without knowing absolutely nothing about mencoder (which is still a tool for advanced encoding users like us :)).
So they should familiarize themselves with the term "reference" which is already a popular one (especially for AVC), instead of the pyramid thingie that, granted, sounds cool but also very very technical.
So technical that, for example, I've never heard sysKin using this name before akupenguin introduced it, despite the fact that on the topics of motion estimation and frametype decision, sysKin knows one or two things more than all of us ;)

Anyway, usually in VfW the names try to be as simple and direct as possible.

x264.exe - Entry point not found
The procedure entry point AVIFileExit cound not be located in the Dynamic link library MSVFW.DLL
Something is wrong here. This has something to do with bobololo's patch for AVI/AVS input in x264.exe afaict, though I've never heard of such problems. In fact the patch works ok for me, and mind you I'm on Win98SE. So if it works for me, it should work for everyone :)
(btw I have a library called msvfw32.dll *not* msvfw.dll, and I've been told that the name msvfw32.dll seems to be the right one under both 9x and NT kernels... are you sure you didn't screw up things? and which is the last revision which worked for you?)

[scorpdt]

I hope this is the right place to post my problem .... as I am not sure whether the problem lies with x264 codec or the mencoder itself.

The issue being ....

I have a movie which is 3 hours long, it is my plan to encode the whole movie using mencoder (MeGUI) into 2 CD. I had the audio encoded separately into aac_he 6 channel. Feeding the avs script and audio into MeGUI returned me the projected video bitrate of 886 kbit/s (I trust that value).

Before embarking on the whole movie encoding, I did a small sampling of 900 frames (using Trim in avs script) of a specific scene (music video) and run an Automatic 2 Pass @ 886Kbps bitrate (see attached log file (http://www.logisticshub.com/uploads/misc/VZ-Log1.txt)) and also the output AVI file (http://www.logisticshub.com/uploads/misc/VZ-900Frames-886Kbps.avi).

Next I did another sampling of 12255 frames (adding 11355 frame to the above) and run an Automatic 2 Pass @ 886kbps (see attached log file (http://www.logisticshub.com/uploads/misc/VZ-Log2.txt)) and also the output AVI file (http://www.logisticshub.com/uploads/misc/VZ-12255Frames-886Kbps.avi)(44MB).

Now should you are to compare the output you would expect the 1st 900 frames of the 2nd encoding would be close to the 1st sampling did above .... but they are not. The quality of the 1st 900 frames in the 2nd encoding is much much lower. Should you are to look at the skyline there are a lot of block pixels which points to lower bitrate. I did a cut-out of the 1st 900 frames using VDM and save the cut-out AVI file out (http://www.logisticshub.com/uploads/misc/VZ-0-900Frames-886Kbps.avi). Loading the cut-out file back on VDM, I found the average bitrate is 401kbps.

I am not sure what influence the kind of output I am getting .... so can someone help analyze and probably determine where the problem lies ... x264 or mencoder?.

FYI, I am using the latest x264 (build 177) and latest mencoder (dev-CVS-050315) ... the same problem happens on earlier builts for both.

Lastly, my apology if my explaination above confuses you. But please look at the files (both the log and AVI file) to understand the problem I mentioned above and please post you thought and possible solution.

Cheers!
Scorpio

[Ghim]

Originally posted by scorpdt
I hope this is the right place to post my problem .... as I am not sure whether the problem lies with x264 codec or the mencoder itself.

The issue being ....

I have a movie which is 3 hours long, it is my plan to encode the whole movie using mencoder (MeGUI) into 2 CD. I had the audio encoded separately into aac_he 6 channel. Feeding the avs script and audio into MeGUI returned me the projected video bitrate of 886 kbit/s (I trust that value).

Before embarking on the whole movie encoding, I did a small sampling of 900 frames (using Trim in avs script) of a specific scene (music video) and run an Automatic 2 Pass @ 886Kbps bitrate (see attached log file (http://www.logisticshub.com/uploads/misc/VZ-Log1.txt)) and also the output AVI file (http://www.logisticshub.com/uploads/misc/VZ-900Frames-886Kbps.avi).

Next I did another sampling of 12255 frames (adding 11355 frame to the above) and run an Automatic 2 Pass @ 886kbps (see attached log file (http://www.logisticshub.com/uploads/misc/VZ-Log2.txt)) and also the output AVI file (http://www.logisticshub.com/uploads/misc/VZ-12255Frames-886Kbps.avi)(44MB).

Now should you are to compare the output you would expect the 1st 900 frames of the 2nd encoding would be close to the 1st sampling did above .... but they are not. The quality of the 1st 900 frames in the 2nd encoding is much much lower. Should you are to look at the skyline there are a lot of block pixels which points to lower bitrate. I did a cut-out of the 1st 900 frames using VDM and save the cut-out AVI file out (http://www.logisticshub.com/uploads/misc/VZ-0-900Frames-886Kbps.avi). Loading the cut-out file back on VDM, I found the average bitrate is 401kbps.

I am not sure what influence the kind of output I am getting .... so can someone help analyze and probably determine where the problem lies ... x264 or mencoder?.

FYI, I am using the latest x264 (build 177) and latest mencoder (dev-CVS-050315) ... the same problem happens on earlier builts for both.

Lastly, my apology if my explaination above confuses you. But please look at the files (both the log and AVI file) to understand the problem I mentioned above and please post you thought and possible solution.

Cheers!
Scorpio

When you do a 2-pass encoding, you get a variable bitrate video, which is perfectly fine. It's up to the encoder and its rate control to give more or less bitrates for the different parts of the video. On the 12255 encode, the codec probably estimated that some parts after the 900 first frames required more bitrate (due to higher temporal or spatial complexity by example). That's why you get a lower bitrate (401 kbps) on the 900 first frames...
There is no problem at all in this behaviour....

[Sharktooth]

Try lowering the bitrate variability and see if it helps.

[scorpdt]

Thanks Ghim .... I aware that is what 2-pass encoding does, but could not figure out why the variation is so great. In fact I just completed encoding the 12255 frames sampling on Nero Recode (6 ref, 0 b-frame, cabac, macroblock,deblocking, chroma optimize and adaptive [auto smooth])and the result is comparable to that of the 1st sample I did except that Nero takes 2 hours to encode. BTW, should you look at the 1st pass of job2-1 i.e. the 2nd sampling, the it returns 2463.8 kbps ... so? Perhaps there might be a way to control this variation and this points to what Sharktooth suggest "lowering the bitrate variability .... so pardon me Sharktooth for my ignorance .... how do you do that .... which parameter must I tweak.

Thanks in advance.

Cheers!
Scorpio

[baer999]

I can see that x264 is still in development, but my question is if Nero Digitals 264er codec will become better or do they stop their development, because I haven't heard of them for quite a long time !

[IgorC]

it just simply says : bitrate varibiality 60% as default.

[Sharktooth]

Uhm, in mencoder it should be the ratecontrol sensitivity option.

[scorpdt]

Thanks IgorC .... saw that on VDM.

Sharktooth ... on mencoder i.e. via MeGUI ... that setting is disable for Automated 2pass .... perhaps Doom9 can help reason out why it is disable.

I doing another encode on VDM (should have thought about this earlier)

Cheers!
Scorpio

[Doom9]

from the mencoder manpage:
rc_sens=<0−100> (CBR only)
ratecontrol sensitivity (default: 4)
So, I have my doubts that this setting even corresponds to the bitrate variability setting in the VfW.

I think qcomp=<0−1>
quantizer compression (default: 0.6).
Corresponds to variability in the VfW.. the value and range matches, and quantizer compression basically does limit the bitrate variability. If you look at the manpage description of this switch:
This affects the ratecontrol: a lower value makes the bitrate more constant, while a higher value makes the quantization parameter more constant.And this setting is not disabled in any mode.

[Sharktooth]

Yes, it's the qcomp without any doubts :)

[virus]

yes, the equivalent of VfW's "bitrate variability" is called "qcomp" in mencoder, and qcomp = bitrate_variability / 100; in fact qcomp defaults to 0.6.

BTW mencoder's options are explained very clearly in Mplayer's documentation (http://www.mplayerhq.hu/DOCS/man/en/mplayer.1.html) ;)

EDIT: I hope noone will complain that choosing "bitrate variability" as a descriptive name for the option in VfW is confusing n00bs...

[scorpdt]

Thanks Guys it is clear.... get much better output from VDM with BV@ 0.15.
Trying out mencoder now via MeGUI with qcomm @ 0.2.

Cheers!
Scorpio

[Yong]

Originally posted by virus
...Anyway, usually in VfW the names try to be as simple and direct as possible.
Sorry for the late reply...
actually it was too simple for me :D
x264vfw don't have doc, don't have tool tips...
The doc is at Mplayer man page....

Something is wrong here. This has something to do with bobololo's patch for AVI/AVS input in x264.exe afaict, though I've never heard of such problems. In fact the patch works ok for me, and mind you I'm on Win98SE. So if it works for me, it should work for everyone :)
(btw I have a library called msvfw32.dll *not* msvfw.dll, and I've been told that the name msvfw32.dll seems to be the right one under both 9x and NT kernels... are you sure you didn't screw up things? and which is the last revision which worked for you?)
Sorry, typo:rolleyes:,
it's msvfw32.dll...
I'm on WinXP SP1,
I won't touch the source code, before i compile x264,
I thinks r15x... of x264.exe work for me...
recently i have many many problem with my own compiled x264vfw,
example:
1. it doen't shown up the "about" window when i click the x264vfw about button at VD/MOD and tmpgenc....
2. When i try to encode video using CBR mode or Constant Quant mode,
x264vfw pop-up a "console message": "could not find x264 2 pass stats file...":eek:
CBR or Constant quant need 2pass stats file?
3. the "console message" window too small,the "OK" and "Cancel" button were "truncated"...

[virus]

@Yong:

I have no clue about your problems, except for a single thing which may or may not be related.
You said that r15x worked for you and then you had problems. Well, I had some problems with mencoder+x264 around rev 150 or 151 too: mencoder kept crashing each time I started an encode. The "culprit" was apparently MingW 3.1+gcc 3.2.3 I was using. I updated to 3.2RC3+gcc 3.4.2 and everything worked again. Maybe you're using an old gcc too?

[Yong]

Originally posted by virus
@Yong:

I have no clue about your problems, except for a single thing which may or may not be related.
You said that r15x worked for you and then you had problems. Well, I had some problems with mencoder+x264 around rev 150 or 151 too: mencoder kept crashing each time I started an encode. The "culprit" was apparently MingW 3.1+gcc 3.2.3 I was using. I updated to 3.2RC3+gcc 3.4.2 and everything worked again. Maybe you're using an old gcc too?
I think i must update the Msys and Mingw32..
I never encountered crash with encoding mencoder+x264, when i was start compiling x264(start form r15x) and mplayer myself,
execpt some compiling problem with mplayer.
I will post the result on tomorrow(may be)...:)

[Yong]

@virus:
After upgraded to MinGW-3.2.0-rc-3 and binutil , all problem are gone except first problem(see my last post),
But still can view the "about" window via resource hacker:)

[Sergejack]

I've got a buggy video that crashes players.

http://users.skynet.be/EAF/naruto_39op30fpsV2ns.avi

params :
up to 4 B-frame, usable as reference; spacial prediction.
min max IDX : 100-1000
3 pass , first one not turned to fast mode.

[skal]

Hi,
Originally posted by Sergejack
I've got a buggy video that crashes players.

This bitstream seems to overflow picture buffer capacity (DPB_Size)...

-Skal

[ksnif]

Hi,

I've noticed that there is a native decoder missing from the x264 distribution. There is a decoder in the source code, but as the developers say, it is "unusable". Is there a reason for leaving the decoding side behind? is ffdshow covering all decoding needs?

I'd like to contribute to x264's development (if I'll ever find some free time). I see that the "decoder" is part of the todo list, so I could look at that (I think...). I need the standard though. Does the development team have a copy of this or is it up to me to purchase it?

regards

keep up the good work!

[bond]

ksnif, you might want to join #x264 on irc.freenode.net :)

[ksnif]

:) thanks

[Leo 69]

Has the development stopped ?

[Manao]

Not at all. It just happens that Aku / Loren is away for a week. Development should resume ASAP after his return, i think.

[Neo Neko]

Originally posted by ksnif
Hi,

I've noticed that there is a native decoder missing from the x264 distribution. There is a decoder in the source code, but as the developers say, it is "unusable". Is there a reason for leaving the decoding side behind? is ffdshow covering all decoding needs?

I'd like to contribute to x264's development (if I'll ever find some free time). I see that the "decoder" is part of the todo list, so I could look at that (I think...). I need the standard though. Does the development team have a copy of this or is it up to me to purchase it?

regards

keep up the good work!

FFmpeg/ffdshow is pretty much covering all the decoding needs as you put it. But that should't bar you from trying. There are a few things ffdshow is not yet doing IIRC. Like automatic post processing. You can set it manually. But IIRC it is supposed to do it automatically according to flags in the bitstream.

[MSlv]

There hasn't been a new build for some time now. Should we blame the lack of developers? Or the new builds aren't public yet?

[Sirber]

code is on the SVN and the SVN is public. I'd say lack of dev :(

[Manao]

MSlv : look my answer two posts up.

Neo Neko : what you call automatic postprocessing is in fact adding the noise removed by the encoding during the decoding. It just has been normalized, it is part of the high profile, and it needs the encoder to analyse that noise during the encoding process.

So for the moment, FFDShow / ffmpeg is up to date, since no encoders that i know of support such 'noise' flags.

Edit : up to date, in that regard, of course. It lacks interlacing and high profile support, the first one being a living nightmare, while the second is really promosing

[MSlv]

Originally posted by Manao
MSlv : look my answer two posts up.
Sorry. I should've payed more attention and read the posts.

So new builds should be out soon. cool.
Thanks

[hpn]

Nice to see the x264 development is still alive (rev.179), although the future role of akupenguin still remains a mistery, at least for me.

[ksnif]

Hi everyone,

I'm trying to build libx264.dll using MS VS 6. I get the following error:

../..\common/common.h(278) : error C2485: 'align' : unrecognized extended attribute

actually I get several of these errors about "align". is there something I should include/copy ? I use cygwin's nasm. Is that a problem?

thanks in advance!

[Sharktooth]

If you have cygwin why don't you use gcc for building x264?

[ksnif]

Originally posted by Sharktooth
If you have cygwin why don't you use gcc for building x264?

I'm relatively new in software development, so I'm not very familiar with the tools. I actually use the GNU tools rather than MS's ones. I'll try to compile the dll with gcc. if you have any useful tips for me that would be nice :)

...that’s kind of embarrassing. I want to contribute to x264 project and I can not seem to get the compilation state right!:rolleyes:

[Sharktooth]

Try with revision 180 and MSVC.
However if you look at the x264 daily builds thread you will find all the info you need to compile x264 with gcc.

[ksnif]

Originally posted by Sharktooth
Try with revision 180 and MSVC.
However if you look at the x264 daily builds thread you will find all the info you need to compile x264 with gcc.

Thank you Sharktooth. I never looked further down that thread. being a sticky I though it wouldn't have anything else. I've already build the dll with gcc (didn't test it though yet). I've just tried now revision 180 with MSVC but I get the same error. I must be forgetting something.

Thanks again!:)

[akupenguin]

Originally posted by ksnif
I'd like to contribute to x264's development (if I'll ever find some free time). I see that the "decoder" is part of the todo list, so I could look at that (I think...). I need the standard though. Does the development team have a copy of this or is it up to me to purchase it?
You can download it from ITU (http://www.itu.int/rec/recommendation.asp?type=folders&lang=e&parent=T-REC-H.264) (Yes it's a store, but they give you 3 free recs annually (http://www.itu.int/publications/bookshop/how-to-buy.html#free))

[Sagittaire]

with rev 179 bref work well for me ... thanks Manao

Edit: Playback is good but quality is not better ...

[bond]

Originally posted by akupenguin
You can download it from ITU (http://www.itu.int/rec/recommendation.asp?type=folders&lang=e&parent=T-REC-H.264) (Yes it's a store, but they give you 3 free recs annually (http://www.itu.int/publications/bookshop/how-to-buy.html#free)) i also link to a version of the specs in the mpeg-4 info sticky

[hpn]

I just got curious and downloaded the 1864049 bytes PDF recommendation approved in 2003-05, but the ITU site reports a "superseded" status for this particular version. Akupenguin, is this the document that you are using when coding x264 or there is a newer one? I can see that the "in force" version approved in 2005-03 is yet to be published. Probably the Bond's draft version linked in the sticky is even older, but the PDF is damaged and won't open so I couldn't check.

[akupenguin]

The newer version (that's not published yet) only differs in that it contains high profile. For x264, I use the version I linked (which is 2004-05).

[ac-chan123]

i have found an other h.264 implementation(decoder only).
you can find the source and the papers at :
http://www-user.tu-chemnitz.de/~mfie/stuff/SA/

maybe it gove you a new idea. The paper h264-pres.pdf is german but h264-paper.pdf is english. The source it self seams not be commened.

[baer999]

Oh I am so happy that the coding on the codec are still going on, I thought that it would be the end when one of the best coders went to Nero... but now there come new releases every day like a month ago ! That's great and I hope there will be some good coders which will take part in this project, I can only VB6, HTML, PHP, Delphi but I can't C++... what have I learn to, to help the project ? When I can C++ I doesn't know really much about video coding, so can anyone give me a hint ? thx

[defunkt]

I'm finding the following PDF's a very useful starting point...

www.vcodex.com/h264.html (http://www.vcodex.com/h264.html)

[baer999]

OK thx now I can see the way it goes. When I could C++ and understand the way it is going, then i could help at the coding work or is there any other part I must learn or know ?

[zombi55]

Hi

I have a small request to make! Could you nicely add a key "DisplayVersion" with the n° of the version (rev), the build or the core

Ty

Zombi55 :)

[TripleA]

Originally posted by baer999
Oh I am so happy that the coding on the codec are still going on, I thought that it would be the end when one of the best coders went to Nero... but now there come new releases every day like a month ago ! That's great and I hope there will be some good coders which will take part in this project, I can only VB6, HTML, PHP, Delphi but I can't C++... what have I learn to, to help the project ? When I can C++ I doesn't know really much about video coding, so can anyone give me a hint ? thx

If open source projects died when one developer ceased working on them, for whatever reason, the whole concept would have ceased to exist long ago.

The very idea of open source is to facilitate transition from one generation of developers to the next with as little disturbance as possible so that good code will live on after it's abandoned by its original coder(s), for whatever reason(s).

Unlike closed source: take Xing MPEG Player as an example; this thing was written way back at the dawn of the MPEG age in 1997, yet it's still in use today in the local market around me. The reason? It works. Does its job better than anything else. Excellent code. Never to be built on because it's closed source. Sad.

As to the situation with former x264 devs, hey! look at the bright side: Nero's CODEC will soon get so much better and this will: a) provide more choices for users and b) provide some healthy competition for the open source developers.

;)

[Stacey Melissa]

Is it bad when the first pass returns negative kbit and size values? I've been messing around with the qp_constant parameter in an attempt to get it reasonably close to my target bitrate on the second pass, as suggested in the mencoder command documentation.

My encoding batch file works with 1000 frame clips of the same movie (The Matrix), but returns negative kbit and size when the whole movie is encoded.

I'm using CD's March 15 AthlonXP compile of mencoder.

The mencoder commands in my encoding batch file:

mencoder "The Matrix.avs" -noaspect -aspect 16:9
-ovc x264 -o NUL: -passlogfile "The Matrix - mencoder.log"
-x264encopts pass=1:frameref=2:bframes=5:nob_pyramid:4x4mv:
deblockalpha=-1:deblockbeta=-1:log=0:noweight_b:nochroma_me:
rc_buffer_size=3600:qp_constant=16

mencoder "The Matrix.avs" -noaspect -aspect 16:9
-ovc x264 -passlogfile "The Matrix - mencoder.log"
-x264encopts pass=2:frameref=2:bframes=5:nob_pyramid:4x4mv:
deblockalpha=-1:deblockbeta=-1:log=0:noweight_b:nochroma_me:
rc_buffer_size=3600:bitrate=1800
-o "The Matrix.264" -of rawvideo


The source AVS, from which I've made several successful encodes using other mencoder params:

LoadPlugin("C:\PROGRA~1\4ceCore\DGMPGDec\DGDecode.dll")
LoadPlugin("C:\PROGRA~1\4ceCore\AviSynthPlugins\UnDot.dll")

mpeg2source("D:\Documents and Settings\All Users\Documents\
My Videos\DVD\The Matrix\The Matrix.d2v")

trim(62,195915)

crop(0,62,720,352)

Undot()

And here's the output of my batch file, halfway through the second pass, with the weird part in italics:

Encode x264 video and AAC audio
Movie title: The Matrix
Bitrate [kbps]: 1800
Set advanced parameters? [y/n]: n

Encoding first pass ...
06:52 PM
MEncoder dev-CVS-050315-21:28-3.4.2 (C) 2000-2005 MPlayer Team
CPU: Advanced Micro Devices Athlon 4 /Athlon MP/XP Palomino (Family: 6, Stepping
: 2)
Detected cache-line size is 64 bytes
CPUflags: Type: 6 MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 0 SSE2: 0
Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE

File not found: 'frameno.avi'
Failed to open frameno.avi
success: format: 0 data: 0x0 - 0x114
AVS file format detected.
VIDEO: [YV12] 720x352 12bpp 23.976 fps 0.0 kbps ( 0.0 kbyte/s)
[V] filefmt:38 fourcc:0x32315659 size:720x352 fps:23.98 ftime:=0.0417
Opening video filter: [expand osd=1]
Expand: -1 x -1, -1 ; -1 (-1=autodetect) osd: 1
==========================================================================
Opening video decoder: [raw] RAW Uncompressed Video
VDec: vo config request - 720 x 352 (preferred csp: Planar YV12)
Could not find matching colorspace - retrying with -vf scale...
Opening video filter: [scale]
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
SwScaler: using unscaled Planar YV12 -> Planar YV12 special converter
Selected video codec: [rawyv12] vfm:raw (RAW YV12)
==========================================================================
Writing AVI header...
ODML: vprp aspect is 16384:9193.
ODML: vprp aspect is 16384:9193. Trem: 0min 0mb A-V:0.000 [0:0]
ODML: Starting new RIFF chunk at 0MB.: 0min 0mb A-V:0.000 [2294:0]
ODML: Starting new RIFF chunk at 1023MB. 0min 0mb A-V:0.000 [2474:0]
Pos:8168.6s 195855f ( 0%) 5fps Trem: 0min 0mb A-V:0.000 [-1678:0]
Flushing video frames

Writing AVI index...
Fixing AVI header...
ODML: vprp aspect is 16384:9193.

Video stream: -1678.254 kbit/s (-209781 bps) size: -1713664313 bytes 8168.794
secs 195855 frames

Encoding second pass ...
06:50 AM
MEncoder dev-CVS-050315-21:28-3.4.2 (C) 2000-2005 MPlayer Team
CPU: Advanced Micro Devices Athlon 4 /Athlon MP/XP Palomino (Family: 6, Stepping
: 2)
Detected cache-line size is 64 bytes
CPUflags: Type: 6 MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 0 SSE2: 0
Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE

File not found: 'frameno.avi'
Failed to open frameno.avi
success: format: 0 data: 0x0 - 0x114
AVS file format detected.
VIDEO: [YV12] 720x352 12bpp 23.976 fps 0.0 kbps ( 0.0 kbyte/s)
[V] filefmt:38 fourcc:0x32315659 size:720x352 fps:23.98 ftime:=0.0417
Opening video filter: [expand osd=1]
Expand: -1 x -1, -1 ; -1 (-1=autodetect) osd: 1
==========================================================================
Opening video decoder: [raw] RAW Uncompressed Video
VDec: vo config request - 720 x 352 (preferred csp: Planar YV12)
Could not find matching colorspace - retrying with -vf scale...
Opening video filter: [scale]
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
SwScaler: using unscaled Planar YV12 -> Planar YV12 special converter
Selected video codec: [rawyv12] vfm:raw (RAW YV12)
==========================================================================
Writing AVI header...
Pos:3337.0s 80013f ( 0%) 7fps Trem: 0min 0mb A-V:0.000 [1680:0]

[Sirber]

CPUflags: Type: 6 MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 0 SSE2: 0
Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE
Could be that. From what I see, your Athlon XP doesn't have SSE, and your mencoder id compiled for it.

[Sharktooth]

Every athlon xp have SSE.

[Stacey Melissa]

I've done quite a few encodes with this build, but I've never noticed any issues with it before. In any case, the encode seems to have worked quite beautifully. So no obvious problems. Now I just wonder whether there is anything lurking beneath the surface. That, plus I wonder whether I should still work on adjusting qp_constant to get it closer to the target bitrate, given that I don't know what the real first pass bitrate turned out to be.

[hellfred]

Originally posted by Sirber
Could be that. From what I see, your Athlon XP doesn't have SSE, and your mencoder id compiled for it.
If you have enough bitrate to get a bootable Linux CDRom or a linux OS installed on your system, try to boot from Linux and check mplayers output. It will then deteced the correct instruction sets for your system. IIRC SSE was disabled on win32 due to some problems with this instruction set. At least my PIII will only output SSE when booted to linux, but not to win32.

Hellfred

[Manao]

Since SSE isn't used in the encoder, it won't be a problem if it's not correctly detected. The instruction sets that really matter are MMX and MMXEXT / iSSE.

Edit : sorry, i was of topic, i thought you were speaking of x264, not mencoder...

[Holy]

I have one question, maybe it has been answered in any way, but I could not find it:

I downloaded the latest build ( X264VFW_rev184_p3 ) and could use it via virtual dub like any divx, xvid and co. I encoded some material but did not install anything for decoding, just have the NeroDecoder for 264 content and it worked, the material starts fine on zoomplayer, but the decoding itself and the image has many many failures, moving pixels and so on. Is it because Nero doesn't decode it correctly or is it because of the very early build of this codec?

Is there any x264-only-decoder? I tried ffdshow once for snow decoding and it worked, but all the other codecs, materials and so on were influenced too much and I also don't want any decoder to come in conflict with the NeroDecoder for 264 content when it comes to Recode content.

Thanks for your help :)

[Stacey Melissa]

@Holy - I've had issues with Nero's filter when trying to play back x264 content from AVI. It works well in .mp4 container, though. You'll have to extract to raw .264 stream using avi2raw and then mux the raw stream into .mp4 with mp4creator. Both are part of MPEG4IP tools (http://www.aziendeassociate.it/cd.asp?dir=/mpeg4iptools). Do a search to find out how to use them.

[akupenguin]

Originally posted by Stacey Melissa
Is it bad when the first pass returns negative kbit and size values? I've been messing around with the qp_constant parameter in an attempt to get it reasonably close to my target bitrate on the second pass, as suggested in the mencoder command documentation.
The error is only in MEncoder's UI. It doesn't affect the operation of x264.
To see the actual bitrate, run countquant_x264 (http://students.washington.edu/lorenm/src/x264/countquant_x264.pl) on the statsfile. (Also works for vfw 1st pass)

[Stacey Melissa]

Thanks, akupenguin. That's just the functionality I was needing! Now I'll just have to learn a little Perl to convert it to something my Windows box can use. No biggie - the code looks quite simple, and I've been wanting to pick up some Perl for quite awhile now. :)

[Sharktooth]

Easier solution: download and install Active perl (http://www.activestate.com/Products/Download/Download.plex?id=ActivePerl)

[Stacey Melissa]

Thanks, Sharktooth! That works even better. Looks like I'll have to increase my qp_constant a bit, because that -1678.254 kbit/s was actually a 2527.95 kbit/s first pass. :D

[virus]

Originally posted by akupenguin
To see the actual bitrate, run countquant_x264 (http://students.washington.edu/lorenm/src/x264/countquant_x264.pl) on the statsfile.
Thanks for this one.

But just a note:
All: 1000 avgQP:21.77 avgBits: 2513
I: 16 ( 1.6%) avgQP:18.69 avgBits:22376
P: 283 (28.3%) avgQP:20.83 avgBits: 4836
B: 701 (70.1%) avgQP:22.22 avgBits: 1122

total size: 2513611 = 2.40 MiB = 482.13 kbps @ 23.976 fps
how can 1000 frames at 2513 avgBits sum up to a total of 2.4 MB? I assume you meant bytes not bits?

Also... feature request :D
what about modifying the output this way?
total size: 2513611 bytes = 2454.70 KiB = 2.40 MiB
bitrate: 482.13 kbps @ 23.976 fps = 502.72 kbps @ 25 fps =
602.66 kbps @ 29.97 fps

(that's too little of a change to send you a patch :))

virus

[akupenguin]

done.

[yaz]

Originally posted by Sharktooth
Easier solution: download and install Active perl (http://www.activestate.com/Products/Download/Download.plex?id=ActivePerl) sorry for the noobish interruption but ...
- what to download a/o install from there for winxp ?
- would someone make a win32 exe from it ?
- is there sg similar for xvid ? ( i would love that too)

thx
y

[virus]

MSYS users should be able to launch countquant_x264 by simply typing "perl countquant_x264.pl <statsfile>" at the prompt. If it doesn't work, then Perl is probably a part of MSYS-DTK (http://prdownloads.sourceforge.net/mingw/msysDTK-1.0.1.exe?download) and you'll need to install it.

MSYS-DTK is an integration to MSYS which allows to run powerful configuration scripts. It's not required for compiling x264 nor XviD 1.0.x, but apparently it's needed for XviD 1.1.x (that's why I installed it while ago). Probably other projects need it too. So if you like to build your own code, I'd definitely recommend it.

[Stacey Melissa]

Would there be any way to enforce a max bitrate on 2pass encodes? My Athlon XP 1800 chokes on playback when the bitrate spikes above 8500 kbps, so I'd like to be able to set that as a bitrate ceiling. That would also give more leeway to play around with the qcomp value, since I wouldn't have to worry about spikes when increasing qcomp.

[Sharktooth]

The VBV options are not exposed in the VFW interface :( so, i think the only way to do that is thru mencoder or the CLI.

[Stacey Melissa]

That doesn't bother me, since I use mencoder anyway. ;)

[Sagittaire]

Originally posted by Stacey Melissa
Would there be any way to enforce a max bitrate on 2pass encodes? My Athlon XP 1800 chokes on playback when the bitrate spikes above 8500 kbps, so I'd like to be able to set that as a bitrate ceiling. That would also give more leeway to play around with the qcomp value, since I wouldn't have to worry about spikes when increasing qcomp.

IMO lower variablity can solve your problem ...

[Doom9]

i think the only way to do that is thru mencoder or the CLI.VBV in mencoder? Gotta read that manpage again.. I have the lingering feeling that there are quite a few parameters that haven't been in there when I started coding.

[Stacey Melissa]

Originally posted by Sagittaire
IMO lower variablity can solve your problem ...
Yes, it would solve the bitrate spike problem if I used a lower qcomp, but it would do so at the expense of good bitrate distribution.

Originally posted by Doom9
VBV in mencoder? Gotta read that manpage again.. I have the lingering feeling that there are quite a few parameters that haven't been in there when I started coding.
I check the mencoder manpage for new options every day. It's not in there. I'd notice it if it were. :D IIRC, (no)b_pyramid was the most recent option added to the manpage.

[Sharktooth]

in CLI you have this:
--rcsens <integer> CBR ratecontrol sensitivity [10]
--rcbuf <integer> Size of VBV buffer [0]
--rcinitbuf <integer> Initial VBV buffer occupancy [0]
--rceq <string> Ratecontrol equation ["blurCplx^(1-qComp)"]
--qcomp <float> 0.0 => CBR, 1.0 => CQP [0.60]
--cplxblur <float> reduce fluctuations in QP (before curve compression) [20.0]

Don't know if all those options are in mencoder too...

[Doom9]

scenecut and b_sens wasn't there in my original manpage.

rc_init_buffer sounds very much like rcinitbuf, but in mencoder it only seems to apply to CBR, qcomp and cplxblur is there as well, rcbuf seems to correspond to rc_buffer_size but no mention that of VBV. Did somebody forget to mention that in the manpage? Except for rceq all the parameters you mentioned seem to be there, just under a different name.

[celtic_druid]

Last new options added to mencoder were chroma_me and chroma_qp_offset. That was 4 weeks ago.
http://www1.mplayerhq.hu/cgi-bin/cvsweb.cgi/main/libmpcodecs/ve_x264.c

[Yong]

Is the x264.exe(using default options) accept the yuv4mpeg(using mpalyer -vo yvu4mpeg) format?
since x264 is able to encode the yuv file,
but playback is funny,
the video is scrolling:D :D :D
from left to right...
my own compiled x264 don't have avis-in and mp4-out support,
because i have some problem to compile gpac...
and avis-in only avialable for cygwin, which is "b0gus" for me.
when i try to compile x264 with cygwin, it's pup-up some message: unable to locate "cyg.....something.dll", arrrrgh:devil:

more stup1d questions: why avis-input available for cygwin?
i will post gpac compiling problem later:)

[Manao]

> the video is scrolling

You didn't enter the correct resolution for the input video, perhaps ?

> and avis-in only avialable for cygwin

Making it available for msvc is more than easy : link with vfw32.lib, and in x264.c, include windows.h, vfw.h and define AVIS_INPUT.

[Yong]

@Manao:
my simple x264(r196) cli options:
start /low /b /w X264 -o "%userprofile%\desktop\%~n1.264" %1 320x240
The yuv file info:
YUV4MPEG2 file format detected.
==> Found video stream: 0
YUV4MPEG2 Video stream 0 size: display: 320x240, codec: 320x240
VIDEO: [YV12] 320x240 12bpp 30.000 fps 0.0 kbps ( 0.0 kbyte/s)
[V] filefmt:12 fourcc:0x32315659 size:320x240 fps:30.00 ftime:=0.0333
When playing the raw h264 stream:
Cache fill: 10.16% (851968 bytes) H264-ES file format detected.
==> Found video stream: 0
Searching for sequence parameter set... OK!
Searching for picture parameter set... H264: 0x168
OK!
Searching for Slice... OK!
FPS seems to be: 250000/10000
[V] filefmt:30 fourcc:0x10000005 size:0x0 fps:25.00 ftime:=0.0400
what's wrong with it?

btw thanks for the msvc tips, but i know nothing about programming...:p

[ak]

I think x264 expects raw yuv, which you can get with, say,

> mencoder in.avi -nosound -ovc raw -vf format=i420 -of rawvideo -o oyt.yuv

or 'ffmpeg -i in.avi out.yuv'

[Yong]

@ak:
omg...
(i wonder why using -vo yuv4mpeg2 and the result video is scrolling...)
it's work :)
thanks:D :D :D

[bill_baroud]

(because yuv4mpeg2 as a little header ? so it doesn't read the correct data if it's expecting a raw frame. well that's pure speculation from my side)

[Stacey Melissa]

@Yong - Would Avisynth input be an option for you when using the CLI? It works well for me, and I don't even have to specify the input resolution.

In fact, I'm glad I tried the CLI out, since it seems to be just as easy to use as mencoder, plus it doesn't have the quirks with aspect ratio support, or the extra frame at the end of every encode.

@Sharktooth - I had already been using bitrate*2 for the rc_buffer. (Mencoder's default is bitrate*1.) I'm testing out further adjustments to see if that helps any. As for rceq, I have no idea how I could use that to enforce a bitrate ceiling.



One other thing, while I'm thinking of it... I checked to see that the CLI exposes all the same options that mencoder does. According to the CLI's help screen, there is no way to turn off chroma ME. But --no-chroma-me will turn it off. There also is no mention of a way to set the CABAC IDC, and I couldn't figure out anything either. Besides those two missing items, the CLI has everything mencoder does, and then some. Quite a few of the defaults are different, though. Looks like I'll be using CLI instead of mencoder from here on out. :)

[CREXbzh]

Originally posted by Stacey Melissa
One other thing, while I'm thinking of it... I checked to see that the CLI exposes all the same options that mencoder does.
Just so you know, akupenguin is the guy who's maintaining the x264 section of MEncoder, so it should always be up-to-date and a reliable source of informations.:)

[Yong]

@bill_baroud:
May be,i see some human readable character:
"YUV..." something at the start of the file.(when loading it to hex editor) mplayer also can decode it without any options used.
but this one completely is a raw video files:
mencoder in.avi -nosound -ovc raw -vf format=i420 -of rawvideo -o out.yuv:p

@Stacey Melissa:
I do something stupid before i compiling the x264:rolleyes:
so the x264 won't work...
and now my own compiled x264 work without problems:D

@x264 devs:
Is possible make the x264vfw/mencoder output video frames to mp4?:cool:
Just like the ffvfw, can override the video encoding apps options.
(Because i've heard a lot of bad things about vfw...
and may be the VDub will never support mp4, i hope this just a rumour...):D
Sorry, too many feature requested...:p

edit: cr@zy grammar error and typo..

[Doom9]

mencoder will eventually be able to write mp4 using the libavformat (but so far it's not quite complete yet). Considering the commandline x264 supports AviSynth input and mp4 output... what's wrong with using it?

[Yong]

@Doom9:
Nothing wrong with it,
i don't like avisynth(i'm newbies, still learn how to use avisynth :p), but i need it:rolleyes:
because of x264.exe...
mp4 output is great:cool:

[TheUnforgiven]

cant wait for a CLI build with AVS and MP4 support :(

[Yong]

Originally posted by TheUnforgiven
cant wait for a CLI build with AVS and MP4 support :(
Then Do It Yourself:D,
search this forum for "compiling x264"...
If you have any question please PM me,
But don't expect too much,
i'm newbies only
:D

[TheUnforgiven]

since a lot of members sure have done this already, sharing the build will save a lot of duplicate work for the other members.

[Yong]

I know, but if you want to test the latest functions,
DIY, compiling it is very easy.
shouldn't take too much time to learning it.:)
but downloading time is needed, the mingw filesize is 50359 kb...

[Kurtnoise]

I made a short compile from the last rev (201 right now). Here is the file (http://kurtnoise.free.fr/x264/x264_r201.zip). But only with avs input support. I've an error message during my compilation when I enable the mp4 output support. :(

Compile with minGW. Here is the error message :
gcc -o x264 x264.o libx264.a -lvfw32 -lm4systems_static -lwinmm
c:\MinGW\bin\..\lib\gcc\mingw32\3.4.2\..\..\..\..\mingw32\bin\ld.exe: cannot find -lm4systems_static
collect2: ld returned 1 exit status
make: *** [x264] Error 1

So, if anyone I've an idea to resolve this issue...



Btw, I've a question : for a simple windows users like me :D , what's version is recommended ? The CLI or the VFW ? I noticed that the command line version provide more settings. Is it useful to use it right now ?

Thanks.

[Yong]

@Kurtnoise13:
compiling x264 with mp4-output need GPAC (http://gpac.sourceforge.net/),
just download it from CVS and compile it.
After done compiling,
1. copy the "libm4systems_static.a"
to mingw\lib,
2. copy the folder "GPAC" form "GPAC\include" to mingw\include.
3. type "make clean", "configure" x264 again, and "make --eanble-avis-input --enable-mp4-output"
4. done:D

i preffer cli version of x264, more options to play and mp4 out:cool:

[Kurtnoise]

I can't compile gpac...It needs some external dependices. Too hard for me. So, for the moment you can use my compile and then mp4box to mux the file.


/me waiting Celtic_Druid compile...:p

[Yong]

@Kurtnoise13:
u use cygwin?
I try to use cygwin to compile GPAC,
but:
bash: ./configure permission denied :rolleyes:
dunno what's wrong with it...
Try msys instead:D
It needs some external dependices
DLL?

[Bogalvator]

Yong, perhaps the GPAC folder is specified as read-only?

Also, GPAC needs zlib to compile:
http://www.zlib.net/

[Sharktooth]

My latest build (rev202) supports both AVS input and MP4 muxing.
As usual it's here: http://forum.doom9.org/showthread.php?s=&threadid=89979
Can someone extensively test it and report back please?

[namchik]

Originally posted by Sharktooth
My latest build (rev202) supports both AVS input and MP4 muxing.
As usual it's here: http://forum.doom9.org/showthread.php?s=&threadid=89979
Can someone extensively test it and report back please?
Thanks for your daily.. gonna try it
BTW, why mmx-build only? :confused: i guess 99% of people here have at least sse-optimized CPU's... :rolleyes:

[yaz]

Originally posted by namchik
Thanks for your daily.. gonna try it
BTW, why mmx-build only? :confused: i guess 99% of people here have at least sse-optimized CPU's... :rolleyes: because the users wont gain anything from it (~2-3% if any) but it would double (triple) the efforts of the 'releaser'. imho, it's simple as that ;)
thx
y

[Sharktooth]

My MMX build is 8-10% faster than default builds yet.
Adding SSE or SSE2 only gives a speed increase of about 1%.
The reasons are:
1) the most complex codec parts are written in ASM. So optimizing the C compiler flags doesnt give a significative speed increase.
2) when using SSE, -ffast-math must be disabled
3) -mfpmath=sse is faster than -ffast-math only in certain "situations" but there's no big margin because of 1)

[namchik]

Originally posted by Sharktooth
My MMX build is 8-10% faster than default builds yet.
Adding SSE or SSE2 only gives a speed increase of about 1%.
The reasons are:
1) the most complex codec parts are written in ASM. So optimizing the C compiler flags doesnt give a significative speed increase.
2) when using SSE, -ffast-math must be disabled
3) -mfpmath=sse is faster than -ffast-math only in certain "situations" but there's no big margin because of 1)

thanks 4 the explanation.
but frankly speaking i didn't understand paragraphs 2 and 3 at all :rolleyes:

[Sharktooth]

They're both compiler flags for optimizing performance.

[Sirber]

Originally posted by namchik
thanks 4 the explanation.
but frankly speaking i didn't understand paragraphs 2 and 3 at all :rolleyes: Have fun here (http://gcc.gnu.org/onlinedocs/gcc-3.3.5/gcc/Optimize-Options.html#Optimize-Options)! :D

[easyfab]

Originally posted by Sharktooth

3) -mfpmath=sse is faster than -ffast-math only in certain "situations" but there's no big margin because of 1) [/B]


Sharktooth have you give a try to -mfpmath=sse,387 , it should give better speed (less stability?) because it allows the 2 units x87/MMX and SSE to work in same time.

[Sharktooth]

It crashes when encoding on my system. So i think it's not safe.

[akupenguin]

All those fp settings make negligible difference, not because of the ASM, but because x264 doesn't use any floating-point outside of ratecontrol.

[Sharktooth]

Yep, but there are some SSE(2) integer instructions that are faster than MMX. However the speed gain is negligible.

[IgorC]

I read that H.264 was developed on base of variables of only 16 bits
not compilation 32 bits - float or double. So SSE instructions are useless

[bill_baroud]

with SSE, you can put 8 words (16bits) in one register (128bits) and process them in parallel ... so no, SSE instructions aren't useless at all (well if they can serve h264 purpose, and it should be the case imho).

[Manao]

bill_baround : actually, SSE only do parallel floating point. What is interesting however is SSE2, which does what you're describing. But the speed gain is far less than the one between plain C and MMX, because the memory access time is already the bottleneck for MMX, and SSE2 doesn't help in that regard.

[MacAddict]

Originally posted by Sharktooth
My latest build (rev202) supports both AVS input and MP4 muxing.
As usual it's here: http://forum.doom9.org/showthread.php?s=&threadid=89979
Can someone extensively test it and report back please? Is it just me or have the last couple of builds provided oversized encodes? Might be time for an XP reload:(

[bill_baroud]

hm, yeah, i was re-reading the docs this morning, and saw that i misunderstood the integer SSE part...it use the MMX registers and not the SSE ones. Well the prefetch and cacheability control of SSE for mmx instructions are definitly a plus when memory access is a problem... i guess i'm far from being able to use those sets efficiently.

[Doom9]

Is it just me or have the last couple of builds provided oversized encodes? Did you consider that you're specifying the video bitrate whereas your output size depends on video bitrate + container overhead? Only XviD takes the container overhead (for AVI output) into account when you set a desired bitrate/size. at least in the cli encoder and mencoder, the encoder tells you the video bitrate at the end.. does that match your requested bitrate?

[Kurtnoise]

Hi,

I've request for x264 developpers. May I suggest the avi output type for the x264 CLI ? If I remember, there is already a tool for the conversion : avc2avi. So, merge it directly into x264 core will be great. ;)

Thanks.

[Yong]

Originally posted by Kurtnoise13
Hi,

I've request for x264 developpers. May I suggest the avi output type for the x264 CLI ? If I remember, there is already a tool for the conversion : avc2avi. So, merge it directly into x264 core will be great. ;)

Thanks.
afaik mux AVC to avi is a bad idea...
why not matroska? ;)
the default container fomrat for avc is mp4...
you better go to here "irc://freenode/x264" and ask;)
if you really need this function, then try mencoder:)

[Kurtnoise]

Originally posted by Yong
afaik mux AVC to avi is a bad idea...
I don't think so...

Originally posted by Yong
why not matroska? ;)
because we can't mux raw avc streams into matroska.

Originally posted by Yong
the default container fomrat for avc is mp4..
I'm not sure...for x264 it seems to be raw h264. ;)


BTW, my request is not very important imho. There are lot of things more interesting to implement before.

[ChronoCross]

I think right now everyone is asking for muxing to every format. Here's my opinion.

Avi Muxing == bad idea
mp4 Muxing == good idea but I don't know much about mp4's container capabilities
mkv === I'd enjoy this the most. I love mkv because it's much more versitle than everything else.
Divx's media format === Really horrible atm. wouldn't use it even if they paid me.

[Yong]

@Kurtnoise13:
afaik avi cannot handle b-frame correctly...
(i can't remember, many reason...
where are you Bond, Manao or bobololo :p ? please explain... :D )
i thinks Sharktooth uploaded the cli x264 already can write video frames to mp4.:)
because we can't mux raw avc streams into matroska.
we need volunteers to do it:D

[Doom9]

why spend time on containers? both avs input and mp4 output was not done by the core developers.. if you need avi output, use mencoder or the VfW.. if you want mkv, use whatever input works for you. In fact, GK supports x264 and MKV, so...

[bond]

Originally posted by Doom9
why spend time on containers? both avs input and mp4 output was not done by the core developers.. if you need avi output, use mencoder or the VfW.. if you want mkv, use whatever input works for you. In fact, GK supports x264 and MKV, so... my words
its funny how people cry for supporting some things in a cli encoder and once its here people will surely cry for a gui to be able to use it ;) :D

[ChronoCross]

Well that's because most people who are encoding arent really doing it because they are trying to learn about encoding...rather they are doing it either for production(warez) or because some person thought it would be cool to try out....but most people are too lazy to read docs and whatnot to figure out what it does.

[Sharktooth]

I actually use the CLI encoder, but i would like to have something like Megui for x.264 CLI.
Why? Coz i have WINDOWS installed... not DOS...:)
Remark: I didnt say "I want"... just "I would like to have".

[Stacey Melissa]

Personally, I think anything beyond raw output is just an added bonus. I think the development focus for the forseeable future should really be on the codec itself. If that doesn't work for the warez people, well, tough shit, they shouldn't be doing that stuff anyway.

[Doom9]

but i would like to have something like Megui for x.264 CLI.To be perfectly honest, ever since the cli version got avs input and mp4 output I've been thinking about it.. but at least zoning will have to be done before that.. else I end up making an mp4 that I have to extract to raw and then mux into mp4 again just because people wanna encode credits separately.

But then of course there's also the issue with mencoder getting properly working mp4 output..

[Stacey Melissa]

I've been using a nifty little Excel spreadsheet to do all my calculations, then plugging a few resulting numbers into an even niftier batch file, which then automates practically everything, including command line generation, and even outputs a nice log file. Perhaps the best thing is that I don't have to make Doom9 all cranky with asinine feature requests and poor bug reports. I just fix the thing myself. :D

Still, though, it's long been an idea of mine to make sort of a power user's Recode-type interface to fully automate everything, yet offer manual control where desired, including some cool combing artifact cleanup features that no one has done yet, AFAIK. It's probably all a pipe dream, though, since I'm just a lowly web programmer by trade, and all this C stuff tends to boggle my poor little mind. :p

[Stacey Melissa]

As previously mentioned, I've been trying to achieve lower maximum bitrates without compromising too much on the qcomp value. Per Sharktooth's suggestion, I've been adjusting the rcbuf value, and the results so far have been just the opposite of what I had expected. It turns out that the correlation between rcbuf and max bitrate is positive.

qcomp rcbuf max bitrate
---------------------------
.65 900 7677
.65 1800 7825
.65 3600 8610
.65 5400 8852
.70 900 8246
.70 1800 8380
.70 3600 8505
.70 5400 8710
.75 900 8837
.75 1800 8975
.75 3600 9190
.75 5400 9297
I've been reusing the first pass stats file for each of these encodes. The second pass uses all the same settings, except the varying qcomp and rcbuf. All encodes are done at 1800 kbps. The source is a 185770 frame, 720x352, 23.976 fps AVS from The Matrix: Revolutions. I find the max bitrate of each encode using mp4box -info on the video track of the .mp4.

5.1 channel vbr-streaming HE-AAC is played using the 10/12/2004 ffdshow, and is output as DD5.1 through SPDIF. No pre- or post-processing is done to the audio. Right off the top, the audio sucks up 20-25% of the available CPU cycles from the Athlon XP 1800+. The splitter and video decoder are the latest from Nero, with all PP disabled. WMP10 is used for playback.

Problematic playback areas are during the yellow explosion at the beginning; small parts of the firefight between the APUs and sentinels; and the final battle between Neo and Smith, from when they first contact each other, through the first "mushroom cloud" of water they create.

[MSlv]

About b-frames.
When using them, BSPlayer refuses to play the file and gives me this error message:
"List index out of bounds (0)"
Also, the same file acts strange in videolan. It shows artefacts like this:
http://img64.echo.cx/img64/9279/x264bfrvlc9bm.th.jpg (http://img64.echo.cx/my.php?image=x264bfrvlc9bm.jpg)

Same file plays fine in Media Player Classic.

[Mug Funky]

yet offer manual control where desired, including some cool combing artifact cleanup features that no one has done yet, AFAIK

this sounds interesting!

another thing i'd really love to see is a "segment re-encode" feature (maybe this is best suited to Virtualdub's interface?).

ie. you watch the movie, and note all the crappy bits. you then set I-frame (or IDR frame for AVC, i suppose) in and out points, and re-encode the bad part using the same GOP structure.

i know DVDMaestro offers this (and it's reeeeally nice to use if you've got the Spruce MPX3000 encoder card plugged in - seamless integration with the authoring app). it'd be good to see this built into an mpeg-4 solution - this would mean if your encode is undersized, it's not a problem. it also means if you're using a not-so-good encoder (WMV? Divx 3?) you can still get nice encodes if you re-do enough segments (this is exactly what the feature is for in Maestro - mpeg-2 isn't the best codec, and sometimes a client just wants so much video on a disc that the bitrates go way down).

well, this is also a pipe dream, but i'm sure lots of tweekers would find it useful (the kind who use YATTA for instance :))

[Stacey Melissa]

I hadn't heard of YATTA before. Judging from its description, it sounds like it gets about halfway there for what I was wanting to do to clean up combing artifacts. I'll have to check it out. Thanks. :)

And since you mention setting IDR frames... part of my pipe dream includes the ability to force IDR frames at specified frames. This would be used in combination with the Nero-style chapters that have been recently integrated into mp4box. Chapter seeking would be very fast if the chapter is always set on an IDR frame. Anyway, that would be something nice to have built into x264, although not essential.

And another cool feature to have in x264 would be the ability to use different deblocking strengths for different zones. Maybe that was already planned anyway? I think I've done maybe 30 or 40 encodes of Matrix3, and no matter what x264 parameters I set, I can't get rid of that damn horrendous blocking behind Merv on his balcony. But if I could jack up the deblocking strength to, say, 6, just for that scene, then I'd consider that progress. :D That would at least be one possibility for improving such troublesome scenes. Other possibilities all have to do with fancy AVS wizardry, so I suppose I'll save 'em for another thread. :p

[Doom9]

part of my pipe dream includes the ability to force IDR frames at specified frames. This would be used in combination with the Nero-style chapters that have been recently integrated into mp4box.Is that really necessary? After all, if the playback filter cooperates, you can easily jump to any given frame regardless of its frame type.

[Stacey Melissa]

Of course it's not necessary. It's part of my pipe dream! :p

What it would help with is just making chapter seeking more responsive.

[virus]

some problems here when using b-refs with revision 215... but that's likely a skipping issue so probably a long-standing one. Very weird artifacts due to exaggerate skipping, or maybe some probs with direct mode + brefs, dunno. Anyway, cmdline:

x264 -m 3 -b 3 --b-pyramid --frames 300 -q 27 -o x264-r215-brefs.mp4 ~/mplayer/main/test-2.avs

The result is available here (http://www.webalice.it/riccardo.stievano/video_stuff/x264-r215-brefs.mp4) (627 KB). Look at frames 200 and following. The mess on the woman's face is evident. Frame 230 (according to MPlayer's numbering, ffdshow's may differ) seems the worse.

I got a report (thanks to AlexW) that even decoding with JM the artifacts are there, so it's definitely an encoding issue. The quantizer of bvops is 28-29 here so nothing exceptionally low; not enough to justify such problems, at least. Similar problems happen (maybe even worse) when using -m 5 so it's not directly related to the ME type.

[bond]

Originally posted by virus
[B]some problems here when using b-refs with revision 215... but that's likely a skipping issue so probably a long-standing one. Very weird artifacts due to exaggerate skipping, or maybe some probs with direct mode + brefs, dunno.i can confirm that i get the same problem :scared:

i saw that especially with -q 20 -b 5 --b-bias 100 --b-pyramid


btw the new --progress option rocks! would be cool if it gets enabled by default :)

[akupenguin]

Originally posted by virus
some problems here when using b-refs with revision 215... but that's likely a skipping issue so probably a long-standing one. Very weird artifacts due to exaggerate skipping, or maybe some probs with direct mode + brefs, dunno.
Fixed. The encoding was correct. Only the header was wrong. Old references are forgotten in encoding order, not in order of display timestamp. So when references are reordered (pyramid), having a bigger DPB than expected can change the meaning of "L0 ref 1" to mean something other than what the encoder thought. I didn't notice because only the oldest ref is affected => not very many MBs in B-frames at frameref=8 or 16.

[rushin_911]

feature request: Choosing SAR values from the vfw version...

(I know I've asked that before in this same thread, but I hadn't mentioned the vfw version specifically and at the time this feature had already been introduced in the CLI version)

[Yong]

Why don'y use the CLI x264 encoder?
It isn't hard to use than vfw and more up-to-date imho.
But still i hope x264 devs or other contributors can update this vfw:)

@rushin_911:
You can transmuxing the video to MKV and changing the D/SAR via MKVtoonix.;)

I've tried with MKVToolnix, the D/SAR is ignore by ffdsohw(or haali matroska splitter?)...:rolleyes:
Only MPlayer is respect the MKV D/SAR value.

EDIT: nasty typo...

[Sirber]

I'm thinking about adding CLI in RealAnime, instead of only using the VFW one. Since it supports AVS, it will be easy to implement.

[rushin_911]

Originally posted by Yong
Why don'y use the CLI x264 encoder?
It isn't hard to use than vfw and more up-to-date imho.
But still i hope x264 devs or other contributors can update this vfw:)

@rushin_911:
You can transmuxing the video to MKV and changing the D/SAR via MKVtoonix.;)

I've tried with MKVToolnix, the D/SAR is ignore by ffdsohw(or haali matroska splitter?)...:rolleyes:
Only MPlayer is respect the MKV D/SAR value.

EDIT: nasty typo...

Well the reason for not using the CLI version is that I´m not very familiar with the command line environment...

As for the MKVtoolnix I already use the DAR values from it when muxing into MKV, unfortunatly though it´s, as you have stated, ignored by ffdshow even when enabling overlay and also ignored by Media Player Classic (my player of preference)...

My request for the SAR values to be visible in the VFW however are for when I mux the media files created into the MP4 format.

[Yong]

@rushin_911:
@echo off
IF '%1'=='' GOTO EOF
title X264 Encoder
start /belownormal /b /w X264 -p 1 --stats "%userprofile%\desktop\X264[%~n1].log" -o nul: %1 --progress
start /belownormal /b /w X264 -p 2 --stats "%userprofile%\desktop\X264[%~n1].log" -o "%userprofile%\desktop\%~n1.mp4" %1 --progress
pause
:EOF
save the above code to "x264.bat"
u can try to add other cli option if u need like, --b-pyramid, --weightb and --subme 5.

[Yong]

can anyone play those video clip normally from VSoft's h264 free video clips download section?
http://www.vsofts.com/h264/videoclips.html
Mplayer and ffdshow hang when playing those CIF and D1 video clips...
(becareful, my computer almost freeeeeeze when playing with ffdshow :rolleyes: )

Second, i think there may be a problem in x264 encoders
, when playing x264 encodeds with libavcodec in grayscale mode,
mplayer and ffdshow both show some random big green blocks when playing(extra, flashing green in mplayer),
but HD video clip from apple website doesn't have this kind of problem...

stupid typo again...
Ok, finally i found some playable clips from LEAD h264 free video clips (http://www.leadcodecs.com/Download/H264-Videos.htm) , forget the buggy VSS video clips :D

[dude051]

Can anyone help tell me which values in the VFW are relative to the CLI values? I can pick out all but two, b-frames reduction % and bitrate variability %. I encode mainly Anime, and want to jump to the CLI version to have some of the newer options. My current setup im working with looks like:

@echo off
start /belownormal /b /w x264 -I 300 -i 30 -b 2 -A all -w --b-pyramid --no-chroma-me -p 1 --stats "X264[%~n1].log" -o nul: %1
--progress encode.avs
start /belownormal /b /w x264 --merange 32 -I 300 -i 30 -b 2 -f 1:0 -B 1453 -r 8 -A all -w --me esa --b-pyramid --chroma-qp-offset 2 -p 2
--stats "X264[%~n1].log" -o "encode.mp4" %1 --progress encode.avs

I've heard setting a constant quant as apose to constant bitrate is better, how would i go about guessing one close to my desired bitrate? Also... in the VFW version, does checking "fast firstpass" disable most non-needed cpu intensive things like -A , --me? And im not too sure how different h.264 works compared to XviD, but would it ever be possible to create custom matricies for x264? Although x264's quality vs. noise is alot more impressive than the older codecs, I would like to be able to work on the nasty DCT blocks that show up. Setting the deblocking filter high does not help with this.. as it helps to prevent blocks from already existing blocks. I want to try and help blocks that occur from large flat dark/low contrast areas (such as in most anime). I've searched as much on these questions as much as I wanted to... but its getting late heh.

Thanx in advance...

[Doom9]

but would it ever be possible to create custom matricies for x264?Not until x264 supports the AVC high profile. If you have a look at bond's excellent sticky:
http://forum.doom9.org/showthread.php?s=&threadid=73022 you'll see that the AVC Main profile does not support custom quantizer matrices.

[Sagittaire]

good quality with good speed

x264.exe --bframe 2 --ref 5 --pass 1 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.30 --analyse "all" --weightb --progress -o x264-HDTV.mp4 HDTV.avs
x264.exe --bframe 2 --ref 5 --bitrate 2500 --pass 3 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.30 --analyse "all" --weightb --progress -o x264-HDTV.mp4 HDTV.avs
x264.exe --bframe 2 --ref 5 --bitrate 2500 --pass 2 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.30 --analyse "all" --weightb --progress -o x264-HDTV.mp4 HDTV.avs

"esa" is too slow and quality improuvement is really small
bpyramid don't improve quality and playback is not good

[Yong]

Originally posted by Sagittaire
...bpyramid don't improve quality and playback is not good
Should i say you are kiddding?:rolleyes:

no b pyramid:
x264 [info]: PSNR Mean Y:42.93 U:46.83 V:46.70 Avg:43.66 Global:41.87 kb/s:604.7

b pyramid:
x264 [info]: PSNR Mean Y:42.56 U:46.74 V:46.66 Avg:43.30 Global:42.00 kb/s:601.0

EDIT: So far i haven't encountered any playback problem with b-pyramid...

[bond]

Originally posted by Yong
Ok, finally i found some playable clips from LEAD h264 free video clips (http://www.leadcodecs.com/Download/H264-Videos.htm) omg, what files are these...

- they use wav audio (good for the bandwidth...)
- they place avc in a bastard version of the .ogm format (not listed as video stream)
- they give the .ogm files the .avi extension
- they dont seem to like p-frames, as their streams mainly use b-frames and a few i-frames

funky :D

[Yong]

Originally posted by bond
omg, what files are these...

- they use wav audio (good for the bandwidth...)
yep, uncompressed 1411 kb/s PCM, they are stup1d...
- they place avc in a bastard version of the .ogm format (not listed as video stream)
- they give the .ogm files the .avi extension

OGM? Are you sure?
i see the "RIFF" in the top of file

- they dont seem to like p-frames, as their streams mainly use b-frames and a few i-frames

funky :D
Sure:D

Hey Bond, can u play the free VSS h264 video clips normally?
in my test, mplayer and ffdshow both crashed when playing:devil:

[bond]

Originally posted by Yong
OGM? Are you sure?
i see the "RIFF" in the top of filethe whatbox samples are avi, the others are ogm

Hey Bond, can u play the free VSS h264 video clips normally? the vss clips use an illegal packing of b-frames, which only their own decoder supports

[Yong]

Originally posted by bond
the whatbox samples are avi, the others are ogm

i think we should rename the *.OGM to *.OMG(oh my god):D

the vss clips use an illegal packing of b-frames, which only their own decoder supports
wtf?
SHIFT-DELETE the VSS h264 video clip:sly:

[JoeBG]

Originally posted by Yong
@rushin_911:
@echo off
IF '%1'=='' GOTO EOF
title X264 Encoder
start /belownormal /b /w X264 -p 1 --stats "%userprofile%\desktop\X264[%~n1].log" -o nul: %1 --progress
start /belownormal /b /w X264 -p 2 --stats "%userprofile%\desktop\X264[%~n1].log" -o "%userprofile%\desktop\%~n1.mp4" %1 --progress
pause
:EOF
save the above code to "x264.bat"
u can try to add other cli option if u need like, --b-pyramid, --weightb and --subme 5.

A few questions from a commandline noob :) :
- -o nul: : what is this doing? I hope it makes encoding faster
- %1 : is this for a avisynth input? :rolleyes: Can I start the skript somehow just with making an avisynth-skript and start this skript :confused:;)

Thanks for you help.

[Tommy Carrot]

Originally posted by JoeBG
A few questions from a commandline noob :) :
- -o nul: : what is this doing? I hope it makes encoding faster It means it doesn't create output file in the first pass.
- %1 : is this for a avisynth input? %x (x can be 1-9) is external parameter for the batch file, in this case the input filename.

[JoeBG]

Originally posted by Tommy Carrot
It means it doesn't create output file in the first pass.

This is really helpful, many thanks :)

Originally posted by Tommy Carrot
%x (x can be 1-9) is external parameter for the batch file, in this case the input filename.

How can I use this? To make an example: I have my avisynthskript and I want to use the batchfile for creating an output with the same name like the avisynthskript. Can do this? And how does it work?

Sorry for bagging you :(

[Tommy Carrot]

Originally posted by JoeBG
How can I use this? To make an example: I have my avisynthskript and I want to use the batchfile for creating an output with the same name like the avisynthskript. Can do this? And how does it work?

The most simple way is if you give the same parameter to the input and output field. Using the previously posted batchfile, this would be like this:
@echo off
IF '%1'=='' GOTO EOF
title X264 Encoder
start /belownormal /b /w X264 -p 1 --stats %1.log -o nul: %1.avs --progress
start /belownormal /b /w X264 -p 2 --stats %1.log -o %1.mp4 %1.avs --progress
pause
:EOF

The only problem is that this way you must specify the input name without the extension, for example with "plan 9 from outer space.avs" the command line is:

x264.bat "plan 9 from outer space"

without the avs extension.

[dude051]

A more useful bat file in my opinion, lets you set input, output, stats log file and bitrate. Here's what I use.
@echo off
start /belownormal /b /w x264 -p 1 --stats %3 -o nul: --progress %1
start /belownormal /b /w x264 -B %4 -p 2 --stats %3 -o %2 --progress %1

Using it is simple, just use the command

start x264.bat AVS_Name.avs Output_Name.mp4 Stats_Log.log ##bitrate##

And you should include the .avs extension... you only place quotes ("") around the name if the name includes any spaces. To simplify, keeps your naming down to one word or replace spaces with underscores ( _ ).

[JoeBG]

@ dude051 & Tommy

This is impossible to use for people without DOS knowledge. Open questions are:

@ Tommy

How to start the batchfile. I can create the *.bat and I can save it but noone would ever explain to use it because DOS knowledge seems to be pre-condition. People without DOS knowledge can´t use x264. But I really would like to :)

@ dude051

Originally posted by dude051
Using it is simple, just use the command

start x264.bat AVS_Name.avs Output_Name.mp4 Stats_Log.log ##bitrate##


This is really not fair without instruction to use. But it´s nice that you tell us that you can do this :)

@ All

My question is not o.k in this threat here, but I hoped for help. So forget about it. :)

[dude051]

all you do is create a bat file, in your favorite text editor. Save it as .bat. Bat files are executable, so all you have to do is double click and it will run the commands within it in a DOS window for you. You can either goto Start> Run > Type : cmd , and then type the commands by hand, or make a couple of bat files to do it all for you. Simply enough, place the first set of codes to execute X264.exe in one bat file:


@echo off
start /belownormal /b /w x264 -p 1 --stats %3 -o nul: --progress %1
start /belownormal /b /w x264 -B %4 -p 2 --stats %3 -o %2 --progress %1

Save this as x264.bat

Then create another bat file, with the second set of code:

@echo off
start x264.bat AVS_Name.avs Output_Name.mp4 Stats_Log.log 1000

Bitrate is the last value and is set in Kbps. Save this as encode.bat

Then all you need to do is run encode.bat ( by double clicking it) and it will execute X264 with the commands from x264.bat.

The available commands to X264 can be gotten from running the -h flag... but here:

x264 core:23 svn-215M
Syntax: x264 [options] -o outfile infile [widthxheight]

Infile can be raw YUV 4:2:0 (in which case resolution is required),
or AVI or Avisynth if compiled with AVIS support (yes).
Outfile type is selected by filename:
.264 -> Raw bytestream
.mp4 -> MP4 if compiled with GPAC support (yes)

Options:

-h, --help Print this help

-I, --keyint <integer> Maximum GOP size [250]
-i, --min-keyint <integer> Minimum GOP size [25]
--scenecut <integer> How aggressively to insert extra I-frames [40]
-b, --bframe <integer> Number of B-frames between I and P [0]
--no-b-adapt Disable adaptive B-frame decision
--b-bias <integer> Influences how often B-frames are used [0]
--b-pyramid Keep some B-frames as references

--no-cabac Disable CABAC
-r, --ref <integer> Number of reference frames [1]
--nf Disable loop filter
-f, --filter <alpha:beta> Loop filter AlphaC0 and Beta parameters [0:0]

-q, --qp <integer> Set QP [26]
-B, --bitrate <integer> Set bitrate
--qpmin <integer> Set min QP [0]
--qpmax <integer> Set max QP [51]
--qpstep <integer> Set max QP step [4]
--rcsens <integer> CBR ratecontrol sensitivity [10]
--rcbuf <integer> Size of VBV buffer [0]
--rcinitbuf <integer> Initial VBV buffer occupancy [0]
--ipratio <float> QP factor between I and P [1.40]
--pbratio <float> QP factor between P and B [1.30]
--chroma-qp-offset <integer> QP difference between chroma and luma [0]

-p, --pass <1|2|3> Enable multipass ratecontrol:
- 1: First pass, creates stats file
- 2: Last pass, does not overwrite stats file
- 3: Nth pass, overwrites stats file
--stats <string> Filename for 2 pass stats ["x264_2pass.log"]
--rceq <string> Ratecontrol equation ["blurCplx^(1-qComp)"]
--qcomp <float> QP curve compression: 0.0 => CBR, 1.0 => CQP [0.60]
--cplxblur <float> Reduce fluctuations in QP (before curve compression) [20.0]
--qblur <float> Reduce fluctuations in QP (after curve compression) [0.5]

-A, --analyse <string> Analyse options: ["i4x4,p8x8,b8x8"]
- i4x4
- p8x8, p4x4, b8x8
- none, all
--direct <string> Direct MV prediction mode ["temporal"]
- none, spatial, temporal
-w, --weightb Weighted prediction for B-frames
--me <string> Integer pixel motion estimation method ["hex"]
- dia: diamond search, radius 1 (fast)
- hex: hexagonal search, radius 2
- esa: exhaustive search algorithm (slow)
--merange <integer> Maximum motion vector search range [16]
-m, --subme <integer> Subpixel motion estimation quality: 1=fast, 5=best. [5]
--no-chroma-me Ignore chroma in motion estimation

--level <integer> Specify level (as defined by Annex A)
--sar width:height Specify Sample Aspect Ratio
--fps <float|rational> Specify framerate
--frames <integer> Maximum number of frames to encode
-o, --output Specify output file

--no-asm Disable all CPU optimizations
--no-psnr Disable PSNR computation
--quiet Quiet Mode
-v, --verbose Print stats for each frame
--progress Show a progress indicator while encoding
--aud Use access unit delimiters

You then just add these flags (things with - or -- by them) along with their associated value by adding/changing them in the first bat file, x264.bat. An example would be close to:

start /belownormal /b /w x264 -I 300 -i 30 -b 2 -B %4 -w --b-pyramid -p 2 --stats %3 -o %2 --progress

If you are this scared about using the command line, then I suggest you use the VFW version via VirtualDub or something. This CLI version is a bit more advanced... but is not too complicated once you work with it.

[Doom9]

I have to ask.. why waste time with batchfiles when MeGUI offers you all x264 options, more codecs, more output options, more automatism, jobs, profiles, etc? A lot of the complexity in MeGUI stems from the fact that I try to cater to an advanced audience that could handle batchfiles and such, but why bother with it if you have a GUI tool that can do a lot more?

[dude051]

I actualy have nothing against MeGUI, but I was looking into the CLI version of x264 specifically because I was having errors in vdub with some random crashes. No more crashes or memory leaks since i started with the CLI version. I recently haven't had the time yet to look into MeGUI. Looking into it now actualy and im gonna give it a try.
Thanx :sly:

Edit:
I have to give ya the extreme credit, MeGUI is the holy grail... great stuff! I love it so far.

Later

[JoeBG]

Originally posted by Doom9
I have to ask.. why waste time with batchfiles when MeGUI offers you all x264 options...

A few months ago I asked for my first commandline (mp4box) in the german doom9. The answer was: go to "VHS" (which is a kind of school for adults).

Since then I want to learn more about this. :) And MeGUI is the best!!!

[Doom9]

I'm getting a bunch of

x264 [error]: Error: 2pass curve failed to converge
x264 [error]: target: 1450.00 kbit/s, got: 1387.39 kbit/s, avg QP: 10.0023reported from various MeGUI users.. I was wondering, would it be possible to have an option that automatically lowers the min QP in such a case (or start encoding anyway and just dump a warning rather than exit)?

[akupenguin]

Done. It will still complain, but produce undersized encodes instead of aborting. (If you want the min to be automatically set... just use qp_min=0.)

[Yong]

x264 [error]: Error: 2pass curve failed to converge
x264 [error]: target: 1450.00 kbit/s, got: 1387.39 kbit/s, avg QP: 10.0023
IIRC i only get this kind of warning if transcode WMV without -fps xx options in Mencoder.
The default -fps value for WMV in mencoder is 1000fps:rolleyes:

[Chainmax]

So, does MeGUI allow for access to all of x264 CLI's options? I find x264 CLI a bit daunting after looking at Saggitaire's example batch files and would love something more simplified.

[rushin_911]

Originally posted by Yong
@rushin_911:
@echo off
IF '%1'=='' GOTO EOF
title X264 Encoder
start /belownormal /b /w X264 -p 1 --stats "%userprofile%\desktop\X264[%~n1].log" -o nul: %1 --progress
start /belownormal /b /w X264 -p 2 --stats "%userprofile%\desktop\X264[%~n1].log" -o "%userprofile%\desktop\%~n1.mp4" %1 --progress
pause
:EOF
save the above code to "x264.bat"
u can try to add other cli option if u need like, --b-pyramid, --weightb and --subme 5.

Hey Yong... Thank you for this :) (sorry for my late response)

[Doom9]

does MeGUI allow for access to all of x264 CLI's options?No, there are a few missing (not exposed in mencoder) but I'm pretty sure you won't miss any of them. You really don't need stuff like level, debug, psnr, etc.

@aku: I noted something else.. if you give x264 an empty stats file, it'll throw a curve convergence error.. shouldn't this rather be a "your stats file is invalid"?

[Sagittaire]

and RDO patch ... ???

[Neo Neko]

Originally posted by Doom9
No, there are a few missing (not exposed in mencoder) but I'm pretty sure you won't miss any of them. You really don't need stuff like level, debug, psnr, etc.

If you get time could you add controls on the interface for the -aspect switch in mencoder. Sure I can just paste it in via the comandline builder. But it would IMO make an already excelent tool just a bit better. ;)

[baer999]

Wow I thought the developing is stopped, but now there are a few more versions, my question is:

+ Won a bunch of cycles by not trusting gcc about inlining and
unrolling properly
(about 17% faster globally)

What is 17% faster ? The encoding ? Because i don't know whats is meant by globally :)

[akupenguin]

What does x264 do other than encode? "globally" is benchmarking the whole program, as opposed to listing the speed improvements of one subroutine.

[JoeBG]

Originally posted by baer999
Wow I thought the developing is stopped, ...

A nightmare.....:rolleyes:


@ akupenguin

I hope you´re ok? Everything ok with you and your family? :sly:

[Doom9]

If you get time could you add controls on the interface for the -aspect switch in mencoder. Sure I can just paste it in via the comandline builder.I'll put it into the (already long) todo list. Can't promise it will be in the next version as there is quite a bit of new stuff scheduled already.

[JoeBG]

What makes "--seek" and how do I use it?

Edit:

It´s for stopping the encoding, sorry, I was too fast with this post :(

[Kurtnoise]

Does the --vizualize command work only on Linux/Unix systems ?

I try to compile x264 on win32 platform with some X11 headers but without success...

[Sharktooth]

*nix only :(

[Kurtnoise]

shame yeah...maybe someone can try with a cross-compile ?

[bill_baroud]

well if you need a X11 client, you're somewhat screwed on windows... i think i remember something about one, but it wasn't free iirc.

[nm]

Originally posted by bill_baroud
well if you need a X11 client, you're somewhat screwed on windows... i think i remember something about one, but it wasn't free iirc.

Actually you need an X server (applications are clients) and the free and Open Source Cygwin environment has X.org, see http://x.cygwin.com/

You'll just need to figure out how to compile x264 under Cygwin so that it finds the X headers and libraries.

[Sharktooth]

didnt work for me. maybe i'll try again when i have some time.

[Leak]

Originally posted by Sharktooth
didnt work for me. maybe i'll try again when i have some time.

Works like a charm here; and if you want to build directly under Linux just install coLinux (http://www.colinux.org/) (which is basically a Linux kernel running as a Windows process) and use the X server under windows as a display...

np: Primal Scream - Stuka (Two Lone Swordsmen Remix) (Two Lone Swordsmen - Peppered With Spastic Magic)

[Sharktooth]

well, im redownloading cygwin with X11 and i will try re-building x264.

[nm]

For those unfamiliar with X11, note that X is not just a graphics library, but an entire client-server architecture in which you have to run the server process, X separately. I suppose the Cygwin X project has basic usage instructions somewhere, so be sure to read the documentation. Also try some X applications like xcalc that come with the server (maybe in a separate tools-package, haven't checked myself). If they don't work, nothing else will either.

[Sharktooth]

I managed to compile a win32 build with -visualize enabled but it's useless unless you have cygwin with X11 installed, so i'll keep it disabled...

[Sirber]

Questions:

1) ./configure doesn't like -ffastmath.
2) Can I set -march from ./configure cmdline?

[CREXbzh]

Originally posted by Sirber
Questions:

1) ./configure doesn't like -ffastmath.
2) Can I set -march from ./configure cmdline?

You can edit config.mak after ./configure, that sure works.

[akupenguin]

configure --extra-cflags="-march=..."

[Sirber]

ok. I'll try. Thanks! :D

[Sharktooth]

-ffast-math doesnt work with SSE.

[LigH]

So, revision 237 ff has "zones" now. :thanks:

Unfortunately, not yet in the VfW GUI. -- How long may it take to redesign the dialog?

[Sharktooth]

Im working on the vfw gui, but an average of 5mins/day coz am really busy.
So any help is welcome.

[TNM]

I'm sorry if this question was asked before but for x264vfw, what happen if i set the deblocking filter strength to negative values?

Also about the max and min IDR-frame interval, do they work the same way as xvid's which mean i need to set them according to my vid's fps value?

[CREXbzh]

Originally posted by TNM
I'm sorry if this question was asked before but for x264vfw, what happen if i set the deblocking filter strength to negative values?

Also about the max and min IDR-frame interval, do they work the same way as xvid's which mean i need to set them according to my vid's fps value?

For the deblocking filter, the way I understand it: it has a tendency to wash out some details a bit too much, so if you set it to a negative value, you'll sort of "get back some details".

Please read this doc to get more informations: http://www.mplayerhq.hu/DOCS/HTML/en/menc-feat-x264.html

Regarding max/min IDR-frame, I don't know.

[snacky]

Originally posted by CREXbzh
[B]For the deblocking filter, the way I understand it: it has a tendency to wash out some details a bit too much, so if you set it to a negative value, you'll sort of "get back some details".
I don't agree with this. I think you will see more artifacts than details. You will also see a PSNR decrease in most cases. However I will admit that in pictures with high spatial frequency, detail and artifacts may look similar.
Please read this doc to get more informations: http://www.mplayerhq.hu/DOCS/HTML/en/menc-feat-x264.html
I'd like to point out that this guide argues AGAINST weakening the deblocking filter. The guide suggests that it would be better to conceal artifacts by adding a small amount of noise in playback.

[CREXbzh]

Originally posted by snacky
I don't agree with this. I think you will see more artifacts than details. You will also see a PSNR decrease in most cases. However I will admit that in pictures with high spatial frequency, detail and artifacts may look similar.

I'd like to point out that this guide argues AGAINST weakening the deblocking filter. The guide suggests that it would be better to conceal artifacts by adding a small amount of noise in playback.
Yeah, I did read the your guide (which is the link I gave). I'd just happends that TNM was asking "what happends if the deblocking filter strength to negative values", and you explained it quite well... :)

[Zero1]

Nice bit of a guide there, x264 could do with some more docs like that ;)

While I'm here, can anyone briefly explain --b-bias, I've read in the CLI that it "Influences how often B-frames are used" but as for choosing a value, I have no idea what would be a good realistic value that wouldn't be detrimental to the quality. Say for instance I was using 3 b-frames and b-pryamid, would setting b-bias to 3 be wise?

With regard to the keyint and minkeyint, it would seem logical to me that you do base these on the framerate of your source, just like you would in XviD. I also changed the --scenecut from 40 to 48 (with my source being 23.976 fps), though I'll admit I haven't checked yet to see if it has a good or bad effect on the quality. Bad me :sly:

[bond]

if you have doubts, the best would be to leave the options at default i would say :)

[el divx]

@ x264 devs: When will support for the baseline, main, high & extended profile features that are currently only accessible through cli be added to vfw?

[bond]

@ x264 devs: When will support for the baseline, main, high & extended profile features that are currently only accessible through cli be added to vfw?
all you vfw/avi loving nerds should have a look at the x264 encoder included in ffdshow (yeah it offers a vfw x264 encoder too), it seems to offer as good as all options of x264 ;)

[Doom9]

the core developers are not even workign on the VfW.. so volunteers would obviously be welcome ;)

[celtic_druid]

I added AR (pretty much copy/paste from GUI) just now to VfW. Tested and working here.

[Sirber]

Cool! Thanks!

Could you add also new 8x8 options? :D

[celtic_druid]

I'll see what I can do.

Some other missing options would be:
scene cut threshold
bframe bias
chroma me
chroma qp offset
vbv max bitrate
vbv buffer size
Initial VBV buffer occupancy
min quant
max quant
quant step
Ratecontrol equation
cplxblur
qblur
me method
me range
idc level

and zones.

Ok, I8X8 and 8X8 DCT added. But let me see if I got this right... I8X8 requires 8x8 DCT. I8X8 is enable by default, but 8x8DCT isn't?

Someone want to test this?
http://mirror05.x264.nl/celtic_druid/test/x264vfw.7z

Didn't waste time arranging stuff as it is all going to need re-arranging anyway to fit other options in.

[bob0r]

I'll see what I can do.

..

Ok, I8X8 and 8X8 DCT added. But let me see if I got this right... I8X8 requires 8x8 DCT. I8X8 is enable by default, but 8x8DCT isn't?

Someone want to test this?
http://mirror05.x264.nl/celtic_druid/test/x264vfw.7z

Didn't waste time arranging stuff as it is all going to need re-arranging anyway to fit other options in.

I disabled 8x8dct, you ask us to test what? if it encodes? if it plays back?
I am now encoding default settings + 8x8dct disabled.

1 pass ABR @ 800kbps

[Doom9]

I'd strongly suggest not adding the rc equation as only codec developer know what it does anyway. there's too much potential to screw up in this area.

[bond]

about vbv and levels:
it would rock if the gui would let the user choose profiles and levels, like xvid does it, and automatically adjust the vbv and options allowed to set according to that (+ an unrestricted option)

[Revgen]

I'll see what I can do.


Ok, I8X8 and 8X8 DCT added. But let me see if I got this right... I8X8 requires 8x8 DCT. I8X8 is enable by default, but 8x8DCT isn't?

Someone want to test this?
http://mirror05.x264.nl/celtic_druid/test/x264vfw.7z



I replaced the x264vfw.dll in my ..Windows/system32/ folder with yours. And encoded a file I previously encoded with sharktooth's rev239 build.

The clip is a Garfield and Friends cartoon encoded at 720x480.

Both clips use the same settings except for the 8x8DCT and 8X8i settings included in your .dll

Whats strange is that I was able to play the HP clip in the 2005-05-10 version of your version of FFDshow.

I installed the new June version afterwards and both played fine in that too.


I also can't tell the difference both clips. They both look good.

It might be because the the resolution is too low and because cartoons don't carry as much detail as a motion picture.


I'm going to try and test and resize some 3 Stooges shorts and see if there is a difference.


UPDATE:

I encoded two ivtc'd three stooges clips at 1440x960 1600kbs which were resized from a 720x480 source.

I couldn't notice a difference between the HP one and the regular one.

[Sagittaire]

bug with 8x8dct: frame 29 with this sample (http://multimediacom.free.fr/Video/bug.mp4)

x264.exe --bframe 3 --8x8dct --ref 5 --filter 0:0 --bitrate 896 --pass 1 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.40 --analyse "all" --weightb --me "umh" --subme 5 --progress -o NUL Encodage.avs
x264.exe --bframe 3 --8x8dct --ref 5 --filter 0:0 --bitrate 896 --pass 3 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.40 --analyse "all" --weightb --me "umh" --subme 5 --progress -o NUL Encodage.avs
x264.exe --bframe 3 --8x8dct --ref 5 --filter 0:0 --bitrate 896 --pass 3 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.40 --analyse "all" --weightb --me "umh" --subme 5 --progress -o x264HP-896.mp4 Encodage.avs

but not with this command line (different bitrate: 447 vs 946)

x264.exe --bframe 3 --8x8dct --ref 5 --filter 0:0 --bitrate 447 --pass 1 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.40 --analyse "all" --weightb --me "umh" --subme 5 --progress -o NUL Encodage.avs
x264.exe --bframe 3 --8x8dct --ref 5 --filter 0:0 --bitrate 447 --pass 3 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.40 --analyse "all" --weightb --me "umh" --subme 5 --progress -o NUL Encodage.avs
x264.exe --bframe 3 --8x8dct --ref 5 --filter 0:0 --bitrate 447 --pass 3 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.40 --analyse "all" --weightb --me "umh" --subme 5 --progress -o x264HP-447.mp4 Encodage.avs

[bond]

bug with 8x8dct: frame 29 with this sample (http://multimediacom.free.fr/Video/bug.mp4)
no problem here playing that file with haali + ffdshow, cant you be more specific?

[Sharktooth]

He means this:
http://www.webalice.it/f.corriga/misc/bug.jpg

Btw i decoded it with Nero decoder. FFDShow can decode it without problems.
Maybe the bug is in nero...

[Manao]

With ateme's decoder, it's wrong too ( though the wrong frame is replaced by a surrounding one )

[dinolib2]

Here with mpc, haalis and latest CD ffdshow, plays fine...

[Manao]

Shartooth, bond, dinolib : nero and ateme's decoders are different, and both have problems decoding that clip. Though a test with the JM would be the most efficient way to find the culprit, it is more than likely that the fault lies in x264 / in gpac.

[Sharktooth]

I will post an updated build with the latest GPAC (updated today).

[Sagittaire]

I will post an updated build with the latest GPAC (updated today).

this last build work perfectly (x264cli 253D + ffdshowdec 06/06/05) in my test for all situation (8x8dct, multi-pref, bref, multi-bframe and combinaisons)

very good job ... :)

[bobololo]

He means this:
http://www.webalice.it/f.corriga/misc/bug.jpg

Btw i decoded it with Nero decoder. FFDShow can decode it without problems.
Maybe the bug is in nero...

This stream appears to be broken. Decoding with the JM (9.6) I got a segfault at picture 29, mb 103. Something seems to be wrong with the reference index.

[Sagittaire]

other (old) problem:
bref + 16 pref playback is good now with ffdshow but not with nero dec.

you want bug: I can to find it ... if you want ... lol

[Sharktooth]

Since i will be at home for some days i decided to restart working on the x264 vfw gui (i re-started from the x264gui by virus):
http://www.webalice.it/f.corriga/misc/gui.png
Advanced options are read from a .xml file so it's easier to update.
The .xml file contains the option name, list of values, registry key, etc...
So when a new functionality is added to the core, you just need to update the .xml file to have it in vfw too.
Well, i hope to finish it soon.

[akupenguin]

bug with 8x8dct: frame 29 with this sample (http://multimediacom.free.fr/Video/bug.mp4)
fixed.

[bob0r]

fixed.

Does this mean ffdshow (libavcodec) needs updating again too?

I just did an encode with build 254
-Latest gpac
-Latest ffdshow
-Latest matroskasplitter

x264 build 254 crashes again.

If we indeed need a new libavcodec, i hope celtic_druid is still here tomorrow!

[Sagittaire]

you want bug ... ???

My HPII trailers and the "warner bros" logo is very hard for encoder ... lol

no bug with x264cli rev 253D + ffdshow 06/06/05 but bug with x264cli rev 253D + last nero AVC dec

bug 3: (http://multimediacom.free.fr/Video/bug3.mp4) problem with bref + multi-pref
x264.exe --bframe 3 --b-pyramid --ref 16 --filter 0:0 --bitrate 447 --pass 1 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.40 --analyse "all" --weightb --me "umh" --subme 5 --progress -o NUL Encodage.avs
x264.exe --bframe 3 --b-pyramid --ref 16 --filter 0:0 --bitrate 447 --pass 3 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.40 --analyse "all" --weightb --me "umh" --subme 5 --progress -o NUL Encodage.avs
x264.exe --bframe 3 --b-pyramid --ref 16 --filter 0:0 --bitrate 447 --pass 3 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.40 --analyse "all" --weightb --me "umh" --subme 5 --progress -o x264MP-447.mp4 Encodage.avs

bug 4: (http://multimediacom.free.fr/Video/bug4.mp4) always problem with bref + multi-pref
x264.exe --bframe 3 --b-pyramid --ref 16 --filter 0:0 --bitrate 896 --pass 1 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.40 --analyse "all" --weightb --me "umh" --subme 5 --progress -o NUL Encodage.avs
x264.exe --bframe 3 --b-pyramid --ref 16 --filter 0:0 --bitrate 896 --pass 3 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.40 --analyse "all" --weightb --me "umh" --subme 5 --progress -o NUL Encodage.avs
x264.exe --bframe 3 --b-pyramid --ref 16 --filter 0:0 --bitrate 896 --pass 3 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.40 --analyse "all" --weightb --me "umh" --subme 5 --progress -o x264MP-896.mp4 Encodage.avs


bug 1: (http://multimediacom.free.fr/Video/bug1.mp4) always problem with bref + multi-pref
x264.exe --bframe 3 --b-pyramid --8x8dct --ref 16 --filter 0:0 --bitrate 447 --pass 1 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.40 --analyse "all" --weightb --me "umh" --subme 5 --progress -o NUL Encodage.avs
x264.exe --bframe 3 --b-pyramid --8x8dct --ref 16 --filter 0:0 --bitrate 447 --pass 3 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.40 --analyse "all" --weightb --me "umh" --subme 5 --progress -o NUL Encodage.avs
x264.exe --bframe 3 --b-pyramid --8x8dct --ref 16 --filter 0:0 --bitrate 447 --pass 3 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.40 --analyse "all" --weightb --me "umh" --subme 5 --progress -o x264HP-447.mp4 Encodage.avs


bug 2: (http://multimediacom.free.fr/Video/bug2.mp4) always problem with bref + multi-pref and another frame 29 bug
x264.exe --bframe 3 --b-pyramid --8x8dct --ref 16 --filter 0:0 --bitrate 896 --pass 1 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.40 --analyse "all" --weightb --me "umh" --subme 5 --progress -o NUL Encodage.avs
x264.exe --bframe 3 --b-pyramid --8x8dct --ref 16 --filter 0:0 --bitrate 896 --pass 3 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.40 --analyse "all" --weightb --me "umh" --subme 5 --progress -o NUL Encodage.avs
x264.exe --bframe 3 --b-pyramid --8x8dct --ref 16 --filter 0:0 --bitrate 896 --pass 3 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.40 --analyse "all" --weightb --me "umh" --subme 5 --progress -o x264HP-896.mp4 Encodage.avs

[bob0r]

@Sagittaire
Can you also try if the same bugs still exist with revision 254?
Because maybe the typo fix in 254 fixes more than just 1 bug.

You may have a problem with playback of 254, lets just hope we can fetch an update before all coders are on summer timeout :scared:

[celtic_druid]

Fixed the VfW. DCT8x8 wasn't getting enabled.

[Tommy Carrot]

What is the advantage of "umhex" motion estimation method over the default "hexagon" method? I thought that it might be faster, but apparently it's the contrary, and i cannot really notice any quality improvement when i'm using it.

[Sharktooth]

Uhm... i think there are still some problems with x264 and 8x8 stuff.

http://www.aziendeassociate.it/temp/hp2-x264_8x8-900.avi

watch it with ffdshow and nero...

[Sagittaire]

this "warner bros" logo is very very hard for x264 ... lol

[Revgen]

Fixed the VfW. DCT8x8 wasn't getting enabled.

<SHORT STORY>
I tested the new VfW.

High Profile seems to be working now.

<LONG STORY>

I resized and reencoded my 720x480 3 Stooges clips that I mentioned earlier at 1600kbps and 1440x960 resolution. The HP settings now take longer to encode than the SP. They both took the same amount of time with yesterdays version.

The difference between the SP and HP clips are very small. I have to look at at individual frames in Virtual Dub to see what details are preserved in the HP settings. The HP does preserve details but IMHO isn't worth the extra time to encode.

Part of the reason for this may be that my 3 stooges clips come from a low resolution source, and HP may work better with original HD content.

I'm going to try downloading some non-DRM WMV HD trailers from the Microsoft site and see if I can't get better results.

[akupenguin]

no bug with x264cli rev 253D + ffdshow 06/06/05 but bug with x264cli rev 253D + last nero AVC dec
OK, one of the SPS values was bad, and ffdshow was OK since it ignored that value.

Uhm... i think there are still some problems with x264 and 8x8 stuff.
Both lavc and JM die on the last frame of that clip. Is it a coincidence that the error is there, or can you create a shorter clip with the same error, or are you complaining of something else?

EDIT: oops, truncated download. No, I don't see any errors with either lavc or JM, and seeking works properly in MPlayer.

I resized and reencoded my 720x480 3 Stooges clips that I mentioned earlier at 1600kbps and 1440x960 resolution.
duh. If you upsize by a factor of 2, then there aren't any details.

What is the advantage of "umhex" motion estimation method over the default "hexagon" method? I thought that it might be faster, but apparently it's the contrary, and i cannot really notice any quality improvement when i'm using it.
It is higher quality. On an average movie, I see only something like +.1 PSNR (which is why it isn't the default), but some high-motion clips (e.g. bus.cif) get huge savings. If done optimally, umhex would be only a little slower than simple hex. x264's implementation isn't optimal.

[Sharktooth]

I'll try to recreate with another clip. Btw if you seek forward the video starts to playback normally... then suddenly it gets distorted until the next keyframe.

[Revgen]

I've just downloaded the Amazon 1280x720 clip from the Microsoft site.

I've encoded 40 sec's of the clip at 1600kbps in both SP and HP and I still find no huge differences between the two profiles.

The only way I can still see any differences is by looking at two frames of each clip in Vdub.


That being said, the quality is still much better compared to xvid and divx.

I'm sure it will improve as you guys go further.

[cheburashka]

@akupenguin
Can you comment the last changes in x264 ?
r255 | pengvado | 2005-06-08 19:16:20 +0200 (Wed, 08 Jun 2005) | 3 lines

revert 216, another try at max_dec_frame_buffering.
disable adaptive cabac_idc by default; 0 is always best anyway.
I can't find anything in rev.216 about this.

Thank you

[akupenguin]

http://trac.videolan.org/x264/changeset/216
http://trac.videolan.org/x264/changeset/255

[Selur]

small question:
should 8x8DCT and 8x8 Intra Search even help with normal (dvd resolution sized) encodes or do they only (really) help with higher resolution encodes (asking since after reading up some stuff via googling that high profile is mainly ment for hdtv resolutions)

Cu Selur

[Manao]

It almost always help. It only doesn't when your video is almost not textured ( which happens when you blur it, or when it's a simpson-like cartoon ). Small-res videos tend not to be that much textured, but 'normal' resolution ( over 512xXXX ) should be detailed enough for high profile to be worth it.

[Sagittaire]

8x8dct help always in all situation (metric always better): if you make H264 encoding 720*576 q28 for average quant quality difference between MP and HP could be high but if you make H264 encoding 720*576 q20 for average quant quality difference could be little. IMO HP help very well like all advanced function ... for hard situation.

[Tommy Carrot]

small question:
should 8x8DCT and 8x8 Intra Search even help with normal (dvd resolution sized) encodes or do they only (really) help with higher resolution encodes (asking since after reading up some stuff via googling that high profile is mainly ment for hdtv resolutions)
Cu Selur
The improved efficiency of high profile is a nice addition, but imo the biggest advantage of 8x8 DCT is that it helps reducing the blocking artifacts (or at least makes them less annoying) quite effectively, when i encode something with disabled inloop-filter. Until now h.264 only gave acceptable quality with activated deblocking, and that more or less blurs the video. With 8x8 DCT, we can relatively safely encode without deblocking, so we can get sharper videos as result.

[Tima]

Sorry, I don't know how to tell it corectly..

When encoding 'Tonari No Totoro' ('My Neighbour Totoro') at 1175 kbps I get a lot of blocks in many scenes. Especially on areas with solid colour.

For example, in first scene when the cat bus arrives, there are VERY much blocks on Totoro's back (it's solid grey)..

The problem doesn't disappear even afer denoising (the source is noisy only a little, though). I tried FFT3D with different sigma and default settings of GK (little, medium and heavy)

I used x264 CLI rev 255, 255a (also tried 250, no diffecence) with such comandline:

x264 --pass 1 --bitrate 1175 --bframe 3 --b-pyramid --filter -5:-5 --analyse all --weightb --progress --seek 76950 --frames 200 -o NUL Project_unresized.avs
x264 --pass 2 --bitrate 1175 --bframe 3 --b-pyramid --filter -5:-5 --analyse all --weightb --progress --seek 76950 --frames 200 -o test.mp4 Project_unresized.avs

This result of encoding the full cartoon has this pb too..

Also I use the latest FFDshow (2005-06-09)

(sorry 4 my bad English)

[hpn]

You could also use "reference frames" and "adaptive spatial transform size", so add this to both passes:
--ref 5 --8x8dct

Also 200 frames maybe too little to allow the encoder to do its best, so try encoding at least 2000 (or more)

[Sagittaire]

lol ... you want no blocking why use inloop = -5 ... :confused:

the best setting with h264 is inloop = [-2;0] interval and certainely not inloop = -5 ... :search:

[Tima]

--filter 0:0
The result is nearly the same.

[Sagittaire]

try to make only 1 pass with --qp 25 --filter 0:0 : if bitrate is very higher than 1175 then your source is very uncompressible ...

H264 is a very good codec but not make miracle ...

[hpn]

the best setting with h264 is inloop = [-2;0] interval Is it --filter -2:0 or you mean something else?

This term "best settings" is so speculative, cause it depends exclusively on the source you encode. I dream of a tool that authomatically returns the "best settings" for a given bitrate by doing multiple short encodes with different predefined profiles (sets of settings) and probably comparing the resulting SSIM or PSNR, so I don't have to scratch my head trying to figure out what settings to use every time I encode a new movie :D

[Sagittaire]

0:0 is in practice always the best setting for OPSNR (perhabs not for SSIM). Inloop is adaptative: 0 for quant 25 is not the same deblocking strenght than 0 for quant 20. For low quant (high quality) inloop is in practice desactived. IMO if you want no problem then you must use the default setting for inloop ... ;)

[Tima]

try to make only 1 pass with --qp 25 --filter 0:0 : if bitrate is very higher than 1175 then your source is very uncompressible ...


No, the result is SMALLER (447 KB vs 1.15 MB).

Could you have a look at it?

http://nwfiles.gorodok.net/test.mp4 - --bitrate 1175

x264 --pass 1 --bitrate 1175 --bframe 3 --b-pyramid --filter 0:0 --analyse all --weightb --progress --seek 76950 --frames 200 -o NUL Project_unresized.avs
x264 --pass 2 --bitrate 1175 --bframe 3 --b-pyramid --filter 0:0 --analyse all --weightb --progress --seek 76950 --frames 200 -o test.mp4 Project_unresized.avs



http://nwfiles.gorodok.net/test_qp25.mp4 - --qp 25

x264 --pass 1 --bframe 3 --qp 25 --b-pyramid --filter 0:0 --analyse all --weightb --progress --seek 76950 --frames 200 -o test_qp25.mp4 Project_unresized.avs

[Manao]

You can't do anything about it, except adding noise during the playback ( which is very effective to hide the blocks ) or heavyfiltering the source before encoding it ( which is hard to do ). No option in the codec will help you.

[Tima]

You can't do anything about it, except adding noise during the playback ( which is very effective to hide the blocks ) or heavyfiltering the source before encoding it ( which is hard to do ). No option in the codec will help you.
The pb is that my source doesn't have much noise. :) After basic denoising i can't see any noise at all..

But.. I encoded uncropped source. Could black border be responsible for these blocks?

[akupenguin]

The blocks on totoro's back are caused by noise. It's less visible before compression, but a good temporal smoother is the way to fix it.
Black borders don't directly cause blocking, but they do seriously hurt compression in general, so you'll see lower quants without the borders.
Likewise, multiple reference frames don't directly affect blocking, but they also generally reduce bitrate and thus allow more bits to be spent where they're needed.

[hpn]

Yes, just remove the black borders and you may get quantizers less than that on the screenshot (19). There is really some blocking on totoro's back, but the clip quality is pretty good overall
http://img12.echo.cx/img12/4117/199dq.jpg

[Sagittaire]

try higher inloop ... :devil:

IMO for particular source like anime you can use higher deblocking, inloop [2;4] is better and produce the same visual result than RV10 ...

[Tommy Carrot]

As i said in my previous post (which was ignored somehow), 8x8 DCT helps a lot in reducing the blocking artifacts, definitely worth a try.

[Sergejack]

As i said in my previous post (which was ignored somehow), 8x8 DCT helps a lot in reducing the blocking artifacts, definitely worth a try.

nevertheless inloop keep being usefull :p

[akupenguin]

Accurate deblocking: yes You have postprocessing enabled for h264 ?!

[Tommy Carrot]

nevertheless inloop keep being usefull :p
The fact that 8x8 DCT helps with disabled deblocking doesn't mean that it is not beneficial with activated inloop-filter as well, it should be in all circumstances.

[Maximus_G]

Sorry, i don't see any mencoder/mplayer thread whish is fresh enough.

When i'm trying to start mencoder from mplayer2005.06.09.P3 - i get an error message saying (it's not in english, so this is just a translation):
"Application could not be started, because pthreadGC2.dll could not be found. A new application install may solve this problem."

And Mencoder from mplayer2005.06.04.P3 works just fine. Just I8x8 high profile is unusable, because of inadequate version of mencoder.

Seems like a bug?

[Manao]

Maximum_G : the error message is clear enough. Download the missing dll, and place it in your path. That link (http://forum.doom9.org/showthread.php?t=92726&page=5&pp=20) should help you to find the dll.

[Maximus_G]

Oh, thanks. Maybe then it would be useful to place that link at "x264 win32 daily builds..." thread.

[celtic_druid]

Odd. x264 is using native windows threads and I don't remember enabling pthreads in mencoder. I'll have a look later.

edit: Ok, configure was updated to support mingw pthreads . Previously I had to manually enable it. As such since I had pthreads, it was autodetected.

[Sharktooth]

Oh, thanks. Maybe then it would be useful to place that link at "x264 win32 daily builds..." thread.
It's already there...

[hpn]

You have postprocessing enabled for h264 ?!
Actually I couldn't find a way to disable "Accurate deblocking". It's always "On" (Yes) on the OSD, no matter if I disable or enable postprocessing, but maybe I look at a wrong place or it should always be ON anyway:

http://img176.echo.cx/img176/9746/19b5vl.jpg

[bond]

i assume this refers to loop deblocking. why do you want to disable it?
and if you dont want it you have to disable it when encoding

[LigH]

Somehow it seems hard to distinguish the general DCT based deblocking functions (which shall be deactivated if H.264 video gets decoded) from the H.264 internal deblocking functions (e.g. inloop filter). Just for that reason, the current ffdshow has the long combobox in the lower right part, which allows to disable the usual DCT deblocking when H.264 is decoded, I thought...

[hpn]

I don't want it disabled (I don't even know what exactly it really does), but because akupenguin asked me a few posts above, I thought he was wondering why it's ON, not OFF in this particular case.

[celtic_druid]

Updated the VfW again.
http://mirror05.x264.nl/celtic_druid/test/x264vfw.7z
Added Me method, range and chroma me.

[Tommy Carrot]

Thank you, finally vfw is up to date again. :cool:

I found a small bug though, it seems to me that 8x8 transform is not applied on keyframes, if you could fix this, everything would be perfect. :)

[bob0r]

@celtic_druid

Looks great, x264 rev 260 updated your previous update.
Can you add ,Configure to the .dll?

With celtic_druid VFW still has a great future.... and so does cligui ;)

[celtic_druid]

Well, I'll finish up some stuff and then do a new diff vs. rev 260.
Also the 8x8 bug is as far as I know fixed.

Looks live Configure has been uncommented in the CVS anway.

[bob0r]

..
Looks live Configure has been uncommented in the CVS anway.

That's what i meant :sly:

[Sharktooth]

i submitted all patches i was using to create my builds, including the driverproc.def one (configure).
i confirm the 8x8 thing is fixed in rev260.

[celtic_druid]

Well under debug you can now change the log level to get stats on stuff like 8x8. Default is error.

I also moved fourCC there and put scene change threshold in its place.

Link is still the same: http://mirror05.x264.nl/celtic_druid/test/x264vfw.7z
Diff file: http://mirror05.x264.nl/celtic_druid/test/x264vfwpatch.diff
I also updated the GUI: http://mirror05.x264.nl/celtic_druid/test/x264gui.7z
diffs: http://mirror05.x264.nl/celtic_druid/test/x264gui.diff

[bond]

http://mirror05.x264.nl/celtic_druid/test/x264gui.7z
diffs: http://mirror05.x264.nl/celtic_druid/test/x264gui.diff
thx a lot!
btw it seems there is a problem starting an encode right from inside the gui, because it seems that your build seems to assume that x264.exe is in the path c:\ and not in the folder of x264gui

edit: it seems this only happens when you load defaults (if you dont do it the encoding process starts fine)

btw: can you disable the debug mode by default plz

[LigH]

I like the new detailed GUI in rev. 260A!

I'm not sure what exactly you would like to have tested. But at least I was able to successfully encode a video (see the "Terragen" thread).

Just one issue I faced: Just for fun, I used 4 threads on a single Duron CPU. At the end of the encoding, I get "possible live-locks" (I/O thread not cycled for 10 seconds, later even the main thread). But one click on "OK", and the Dub window closes and the AVI is fine.

[bob0r]

"btw: can you disable the debug mode by default plz"
My thoughts exactly :sly:

And about the x264.exe dir, i think its best to select where x264.exe is when you first run the gui (and after reset load defaults).

Then people know where the x264.exe is, and people know what and where they are working. More knowledge is more test results :)

[hpn]

Just one issue I faced: Just for fun, I used 4 threads on a single Duron CPU. At the end of the encoding, I get "possible live-locks" (I/O thread not cycled for 10 seconds, later even the main thread). But one click on "OK", and the Dub window closes and the AVI is fine.
Actually it's not a real issue, just a warning. The Dub encodes at "Idle" priority by default, so it's very common to get such "not cycled for 10 seconds" messages, if you're doing other stuff with your PC. I often get these when compressing with winrar at the same time for example :)

p.s. The extended vfw dialog is awsome. celtic_druid rocks!

[LigH]

@ hpn:

But the warning list gets longer and longer if I don't close it. It seems to wait for a not correctly terminated thread, in my opinion. But it may be hard to determine the real reason.

Unfortunately, if you try a batch encode (or e.g. GordianKnot running n-pass), each pass would halt here until the user presses "OK".

[hpn]

Unfortunately, if you try a batch encode (or e.g. GordianKnot running n-pass), each pass would halt here until the user presses "OK".
I haven't tried it, cause I've never had such issue with GKnot and multiple passes, but maybe changing the Vdub default priority could help:
Vdub ->Options->Preferences->Process Priority (Norma or High) -> click "SAVE" (not Accept)

(OT here, but anyway)

[SeeMoreDigital]

The new GUI in build X264VFW_rev260A_mmx.exe looks okay: -

http://img172.echo.cx/img172/7416/x264newgui8td.gif

PAR signalling appears to work fine too.... I will do some more tests tomorrow ;)


Many thanks guys

[bond]

i think that "direct mode" and "weighted biprediction" should be grouped together with "b-frames". i dont think they belong to "analysis"

also i wouldnt enable everything by default, eg p4x4 is disabled in mencoder by default, after all enabling everything also slows things down
also i would disable the high profile features by default, cause they will definitely lead to interoperability problems (eg with quicktime). only people who know what they are doing should enable this

[Doom9]

btw, zones are still missing ;)

[Revgen]

I just encoded a Garfield and Friends cartoon episode from my DVD with all default options.

It plays fine in the latest version of FFDShow.

[Sharktooth]

Rev261 is up and contains all the new stuff. We'll discuss the defaults tomorrow (need to sleep now) and maybe even a new fast first pass...

[virus]

Shouldn't "ME range" be disabled for UMH motion estimation too?
Currently it's active, but according to mencoder's documentation it only applies to Exhaustive search.

[celtic_druid]

Haven't looked at mencoders docs but it enables me_rage for me_method >= 3 and me_method 3 = X264_ME_UMH. I just did the same.

[Blue_MiSfit]

Gosh I stop paying attention for one freaking day and all of a sudden theres a new GUI and all sorts of nice improvements!

Open Source development is really far too cool.

:D :thanks:

[Yong]

thx for the new x264vfw interface :)
btw,
a bit headache when i wan to adjust the "ME range value",
so many value i cannot enter... :rolleyes:
eg. 32...

[celtic_druid]

Well you can kinda enter 32. You just have to enter say 12, then change the 1 to a 3. Not sure what to do about it. Guess I could just remove the < 4 check.

Moved the < 4 check so that it checks when it reads from the registry and when it parses the param. So you can now enter a value < 4, but you will just get 4.

[LigH]

Depends on the event you use for validity checks. Being a programmer myself, I experienced that quite often. Better don't check values on each and every change, instead do it only when the focus is taken away from the edit field (don't know how the event handler is called in your programming language: OnExit, OnBlur, ...).

[celtic_druid]

EN_KILLFOCUS I believe. I'll try that.

Ok, that works better.

[Manao]

Usually, text fields needs only to be checked when pressing the OK button. Alternatively, the OK button can be disabled if a field is incorrect. EN_KILLFOCUS has an issue : it isn't necessary called ( i once stumbled accross a blog from a microsoft dev saying not to use the killfocus notification because of that reason ).

[celtic_druid]

Seems to work ok here.

So you think I should just move all of the checks to the OK button?

[Manao]

That's what I would do. The best imho would be a check function that colors the invalid controls and disables the OK button, and to call that function for each EN_CHANGE notifications. But that needs time, and it's not that important.

[LigH]

Okay, there was one issue when I did so:

If I pop up a dialog when the value is invalid, and the focus is removed because I click a button, the button is left in "pressed" state because the dialog pops up. :D

Event driven user interfaces are fun. :sly:

[Kurtnoise]

Great stuff CD...;)

May I suggest some things ? It could be great to separate the Analysis options with B-Frames to help newbies with the advanced settings. Here is some suggestions :

http://kurtnoise.free.fr/motion.png

http://kurtnoise.free.fr/bframes.gif


Another request : to have some presets (High Profile, Main Profile...).

And the last thing : I think the min/max/QP step must be disabled when we choose the Bitrate single pass...

[SeeMoreDigital]

I think there's something not quite right with rev260A. As the encodes I've generated with it will not open in QuickTime player 7 (for Win XP).

I've used exactly the same generating procedure and settings with rev260A, as with the previous version(s) I've tried (last one being X264VFW_rev254+threads_mmx): -

http://img292.echo.cx/img292/6535/x264vfwrev254threadsmmxsetting.gif

But for some reason all my rev260A tests have so far stalled in QT7 (although they seem to work fine in other players).

Please let me know what other info you guys require?


Cheers

[LigH]

I'd rather guess that something is wrong with QT7, only supporting a small subset out of MPEG4-AVC. ;)

[Doom9]

@Kurtnoise13: I like your suggestions.. guess I'll add them to MeGUI as well.

[SeeMoreDigital]

@Kurtnoise13: I like your suggestions.. guess I'll add them to MeGUI as well.Yep.... I like your suggestions too ;)

[bond]

first of all i have to say, cause i often read "weighted prediction", that x264 does NOT support weighted prediction!
x264 supports weighted biprediction, which is a similar, but still another thing than normal weighted prediction


about the guis: yep, having the option to choose between "baseline", "main", "high profile" and "unrestricted" (which automatically en/disables options and sets the vbv) would really rock, this can also be combined with the already available option to set the levels


SMD, i assume you are not trying to open x264-in-avi in qt7, cause this will surely not work

make sure to disable the high profile features (8x8dct and i8x8), cause qt7 doesnt handle high profile
thats also one reason why i wrote that they should better be disabled by default

[Manao]

It's levels, not profiles, that restrain the vbv buffer size.

However, making high profile features default does'nt bother me, they really improve things a lot ( but ok, i really don't care for qt7 compliancy )

[Sharktooth]

Great stuff CD...;)

May I suggest some things ? It could be great to separate the Analysis options with B-Frames to help newbies with the advanced settings. Here is some suggestions :

http://kurtnoise.free.fr/motion.png

http://kurtnoise.free.fr/bframes.gif


Another request : to have some presets (High Profile, Main Profile...).

And the last thing : I think the min/max/QP step must be disabled when we choose the Bitrate single pass...
ME Range is NOT motion vector search range... it's the number of iterations for motion extimation.
Also it "biprediction" not "prediction"...

[SeeMoreDigital]

SMD, i assume you are not trying to open x264-in-avi in qt7, cause this will surely not workNo... of course I'm not ;)

make sure to disable the high profile features (8x8dct and i8x8), cause qt7 doesnt handle high profile.

Thats also one reason why i wrote that they should better be disabled by default This was it thanks bond.... As soon as these two implementations were disabled, the encodes worked fine in QT7.

Many, many thanks

[Sharktooth]

However let's just implement options. It's easier to re-design it once you know how many things it should contain... :p

[Kurtnoise]

ME Range is NOT motion vector search range... it's the number of iterations for motion extimation.
well...indeed. I created this design too fast...;)

Also it "biprediction" not "prediction"...
It's included into B-Frames GroupBox that's why I didn't mention biprediction...,whatever it's not very important IMHO. It was just a picture to illustrate my suggestions...:)


Edit : zones area rocks. Don't forget this. ^^

[cheburashka]

Rev261 is up and contains all the new stuff. We'll discuss the defaults tomorrow (need to sleep now) and maybe even a new fast first pass...

So. What is the fast first pass in VFW gui? Is it the same as MeGUI's turbo mode?

:thanks:

Ok, found myself in sourse code:
if( config->b_fast1pass )
{
/* adjust or turn off some flags to gain speed, if needed */
param.analyse.i_subpel_refine = X264_MAX( X264_MIN( 3, param.analyse.i_subpel_refine - 1 ), 1 );
param.i_frame_reference = ( param.i_frame_reference + 1 ) >> 1;
param.analyse.inter &= ( ~X264_ANALYSE_PSUB8x8 );
param.analyse.inter &= ( ~X264_ANALYSE_BSUB16x16 );
}

That means it is MeGUI's turbo mode for automated 2pass encode + turned off p4x4 and b8x8.

[Maximus_G]

This is what i see when using mencoder "encopts threads=4" on a dual Xeon (HT) system, Win2000Server. Changing priority in MeGUI window doesn't affect this - total average CPU load is stable and about 50%.

And using threads=2 on a regular P4 with HT produces CPU load at about 70-90%.
I wish i could load those Xeons up to 80% too :)

[SeeMoreDigital]

With regard to the existing GUI layout. It's width has increased by quite a bit.

Anyway, I did some shuffling about and came up with this layout proposal: -

http://img138.echo.cx/img138/4294/newguioriginal2xq.png


Cheers

[Sharktooth]

PAR and DAR? No, x264 supports only one...

[SeeMoreDigital]

PAR and DAR? No, x264 supports only one...Well you can't knock a guy for trying :D

I've generated several PAR PAL test encodes using 45:64 (for 16:9) and 15:16 (for 4:3) and they are smack on the money.... Many thanks for including AR signalling via VfW.


Cheers

[Sharktooth]

There are definately other interesting options to include though.
Like zones, VBV, levels, ratetol, qblur, qp offset and chroma qp :)
However i like your design...

[SeeMoreDigital]

There are definately other interesting options to include though.
Like zones, VBV, levels, ratetol, qblur, qp offset and chroma qp :)
However i like your design...Thanks Sharktooth,

Would it be possible to add .MP4 output for VfW users?


Cheers

[berrinam]

Would it be possible to add .MP4 output for VfW users?

How would that work? Isn't the whole point of VfW that it is container independent?

[SeeMoreDigital]

How would that work? Isn't the whole point of VfW that it is container independent?I guess it could work in much the same way it did when DivX 5.0.2 was released.


Cheers

[Sharktooth]

it works the same way... the mp4 file is written to disk by the codec and it returns blank frames to vfw (so virtualdub writes a small and almost empty .avi).
im still working on it though, coz it will support audio (including delay) and subtitles muxing too.

[Yong]

i suggest remove the slider from deblocking filter "strength/thresthold" and b-frames bias,
b-bias already have a box to enter value, so i hope the deblocking filter "strength/thresthold" also have this kind of box to enter value.
coz i feel the slider doesnt useful(not change the value frequently) but only make the "X264 anvanced settings" window bigger... :p :D

[Sharktooth]

the interface is being redesigned.

[Inventive Software]

I have something that might interest the devs...

I can successfully do a 1st Pass, with the information file. When I try and do the Nth pass VDubMod complains that it can't start the compressor. I'm using x264 rev 216, VFW. Is this why?

P.S, this is to with the codec test I'm still trying to get results from. I am getting results from all but 2 or 3 of the codecs on test, no names mentioned except x264. I would like to get 2-pass working, because if not it's gonna hinder it when I come to the final conclusions.

[SeeMoreDigital]

I can successfully do a 1st Pass, with the information file. When I try and do the Nth pass VDubMod complains that it can't start the compressor. I'm using x264 rev 216, VFW. Is this why?Where have you pointed your "Stats File" location to?

http://img228.echo.cx/img228/9017/x264statsfile1qh.png


Cheers

[Sharktooth]

never had problems with 2 or more passes in VFW and never heard of any other report saying it doesnt work.

[SeeMoreDigital]

never had problems with 2 or more passes in VFW and never heard of any other report saying it doesnt work.I only ever have a problem with 2 (or more) pass, if I forget to re-set the "Stats File" location.... Which I place at C:\


Cheers

[Inventive Software]

@SMD: The statsfile is pointed to the file that was created. In trying to get Nth pass mode working, it just doesn't want to start the compressor. Is there something I'm missing?

[SeeMoreDigital]

@SMD: The statsfile is pointed to the file that was created. In trying to get Nth pass mode working, it just doesn't want to start the compressor. Is there something I'm missing?A similar thing happened to me.

All I can tell you is, when I moved the "Stats File" location to C:\ instead of the default location.... it cured my problem ;)


Cheers

[Inventive Software]

Yeah, but I have a directory that has many stats files in it, and some end with .stats, including the x264 ones. I am pointing the stats file to the absolute file that contains the information.

(The forward slashes are actually back-slashes)
Example: I have a stats file in "C:/Codec Test/1st Pass Information Files/Simpsons Roasting On An Open Fire - x264 rev 216.stats". This is where I put the file in the 1st Pass. When trying to do the Nth pass, and pointing to this file for the Nth Pass, it doesn't want to start the compressor. I have absolutely no idea what's going on here, and it's doing my head in.

[Mutant_Fruit]

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.

[jellysandwich]

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

[Revgen]

X264 is still actively being developed. It doesn't even have an integrated decoder yet. You have to use custom versions of FFDshow or Mencoder to view them.

You can make a backup, and it will look better than Xvid, but it might not be compatible in the future.

[snacky]

X264 is still actively being developed. It doesn't even have an integrated decoder yet.
Why should it?
You have to use custom versions of FFDshow or Mencoder to view them.
They're not custom. And any other sufficiently full-featured decoder will decode them too.

You can make a backup, and it will look better than Xvid, but it might not be compatible in the future.

Actually, videos you make today are certain to be compatible with future decoders.

[ChronoCross]

Actually, videos you make today are certain to be compatible with future decoders.

I disagree. if you make a backup of something now and it's b0rked then it will still be borked for future decoders. Bad headers or something implemented wrong, or something not working just right and therefore reducing possible quality. For now I'd say that x264 is a testing codec only not suitable for full featured backups, but from what I'm seeing it won't be long until it's ready for full on backup.

[snacky]

I only know of one instance since last July in which x264 has generated an invalid stream that prevents decoding. Arguably, this is better than xvid's track record.

[Revgen]

Why should it?
It's not practical for mainstream users. They won't be able to easily figure out how to use Mencoder/Mplayer or FFDshow to play a video. An easy plug and play codec is essential if X264 is to be used by the mainstream.

They're not custom. And any other sufficiently full-featured decoder will decode them too.

Look at Sharktooth's sticky page. He recommends using FFDShow builds made by Celtic Druid.

Also there was a post in some thread in this section mentioning an X264 file that wasn't able to play correctly in an H264 compatible player. However the person was able to play it correctly using FFDshow. I did a search for the post but I have still yet to find it to post a link. X264 still has a way to go before being completely compatible.

Actually, videos you make today are certain to be compatible with future decoders.

ChronoCross answered this question better than I could.

[LigH]

Look at Sharktooth's sticky page. He recommends using FFDShow builds made by Celtic Druid.
The main reason is that this build has most libavcodec options enabled.

I read somewhere that plain CVS builds of ffmpeg, for example, have many libavcodec options disabled, this might be true for default ffdshow projects as well.