mencoder+x264

[bond]

my findings:

- RC matches the desired bitrate very accurately (missed by 1kbps in my samples)
- quality very good (comparable to xvid, if not better)
- deblocking seems to be good, but smooths too much in fast moving background+still foreground scenes (eg matrix1: neo in front of the weaponshelf)
- not sure if b-frames help quality atm, will have to check that more closely
- mencoder outputted two frames too much (mpeg4ip's avi2raw tool reports two zero lenght frames too) there seems to be the correct framenumber in the .log files
- when setting 2 consecutive b-frames they are not adaptively set, but i assume thats the expected behaviour
- pretty fast, mencoder displayed 4fps encoding speed with b-frames, cabac and deblocking enabled with my pentium3 866mhz

all in all: very nice!

[celtic_druid]

Older builds all used the same generic libx264.a, in newer builds the XP version got an XP optimised libx264.a and xvidcore.a as did the P4 version (optimised for P4 that is). That would probably explain the Athlon-XP version crashing on a P3.

[akupenguin]

Originally posted by bond
- deblocking seems to be good, but smooths too much in fast moving background+still foreground scenes (eg matrix1: neo in front of the weaponshelf)

The solution there is not adjusting the deblocking, but rather adaptive quant.

- not sure if b-frames help quality atm, will have to check that more closely
- when setting 2 consecutive b-frames they are not adaptively set, but i assume thats the expected behaviour

1 consecutive B-frame isn't adaptive either.
I don't consider B-frames to be usable yet: scenecut detection doesn't work correctly with them (i.e. it will insert I-frames but not IDR, so no seeking). This will be fixed at the same time as I add adaptive B-frames, because it's really the same problem.
But aside from that, they do sometimes help compression. Even without adaptiveness, I've seen as much as +.4 dB psnr improvement for some videos, (and as low as -.5 dB for others).
I also haven't finished subpel motion refinement for B-frames. subq=5 is unaffected, but anything less is suboptimal quality.

- mencoder outputted two frames too much (mpeg4ip's avi2raw tool reports two zero lenght frames too) there seems to be the correct framenumber in the .log files

This with B-frames? Known bug (I recently fixed the same bug in lavc). But that comes after the above issues.

- pretty fast, mencoder displayed 4fps encoding speed with b-frames, cabac and deblocking enabled with my pentium3 866mhz

For whatever reason (unfinished subpel, no 4x4 modes, or just the increased number of SKIP blocks), I find that encoding is often faster with bframes=1 than without.

[bond]

Originally posted by celtic_druid
Older builds all used the same generic libx264.a, in newer builds the XP version got an XP optimised libx264.a and xvidcore.a as did the P4 version (optimised for P4 that is). That would probably explain the Athlon-XP version crashing on a P3.

which build should i use?

Originally posted by akupenguin
The solution there is not adjusting the deblocking, but rather adaptive quant.

hm, does x264 already offer adaptive quant? (btw xvid handles such scenes pretty good even without adaptive quant, dunno how exactly tough)
i noticed that the described behaviour is worse with deblocking, as streams with disabled deblocking didnt show the smoothing that strongly

I also haven't finished subpel motion refinement for B-frames. subq=5 is unaffected, but anything less is suboptimal quality.

what do you mean exactly with "unaffected" and "anything less is suboptimal quality"?

This with B-frames? Known bug (I recently fixed the same bug in lavc). But that comes after the above issues.

nope, this also happens with streams not using b-frames (tested it on two different encodes)

For whatever reason (unfinished subpel, no 4x4 modes, or just the increased number of SKIP blocks), I find that encoding is often faster with bframes=1 than without.

hm, so i assume enabling b-frames, disables 4x4mv? are there any other limitations than the ones you listed atm?

also can you plz describe how to enable exactly the different macroblock types via commandline

also is it necessary to guess the constant quant for the firstpass or is it possible to use something like pass=1:bitrate=650 instead?

to get a better speed is it still possible to use different subq values for 1st and 2nd pass? if yes how big do you think can the difference be (eg for subq=5)?

also where exactly can i find the latest x264 sources? where do you upload them? mplayer cvs/svn, videolan cvs/svn...?

thx and keep up the good work

[celtic_druid]

Well I guess I will put a P3 build up. Probably won't be till tomorrow though. Other option is to compile it yourself or grab the latest from mplayerhq, that is assuming that it is compiled with x264 enabled.

[bond]

Originally posted by celtic_druid
Well I guess I will put a P3 build up. Probably won't be till tomorrow though.

thx a lot!

Other option is to compile it yourself or grab the latest from mplayerhq, that is assuming that it is compiled with x264 enabled.

well, i am not really the one to ask when it comes to compiling

[bond]

ok i now did more quality tests:

- x264 introduced some green color all over the picture (which isnt there when encoding with xvid). it also doesnt seem to be decoder related, as both ffdshow (ffmpeg) and vssh's decoder show this greenish picture
- there seems to be a lot of "movement" in the background, which makes the picture look not really "quiet"
- comparing the detail preservation/sharpness, i would say that x264 is already clearly sharper than xvid in most scenes
- an exception is the already described still-foreground/moving-background smoothing, that xvid (as one of the few codecs existing) is able to handle in a very nice way
- when doing frame-by-frame comparisons, b-frames seem to introduce fluctuating quality (once more details than xvid, once less. i assume depending on whether you look at a b- or i/p-frame)
- in high(medium-high) motion scenes x264 blocks more and shows less details than xvid (even more with b-frames enabled), good seeable in the lobbyshootout (especially the flying wall-parts)
- eg the detailed walls in the lobby shootout seem to get encoded less detailed and more blocky in x264
- regarding flat surfaces (eg, walls) x264 tends to block a lot (ugly) in contrary to xvid, which managed to handle walls very nicely beginning with the introduction of its vhq modes (rdo) if i remember it right
- fog gets encoded more blocky in x264 than in xvid
- x264 shows by far less blocks on "not-flat-surfaces" (eg on edges) especially with deblock, still deblock doesnt seem to visually hurt the details noticably

note that i base these findings on the following settings used to encode the matrix1 scenes, doom9 also uses in his tests, at ~650kbps:
xvid: 1.01_Lanczos_hvs-best_VHQ4_ChromaMotion_QPel_GMC_Trellis_Bvops-2-default_AdaptivQuant
x264: mencoder20041212_Lanczos_Cabac_(no)deblock_alpha-beta:-3,-3_(no)Bvops-2_subq1/5

all in all:
highmotion, the background and flat surfaces (walls) need some tuning imho, the rest kicks ass

[bond]

and if anyone wants to try x264 with 2pass out him/herself, here is a sample commandline similar to the one i use (copy it to a .txt file, adjust the path/filenames, change the extension from .txt to .bat and execute the .bat)

"C:\path to\mencoder.exe" -ss 00:00:00.400 -frames 1000 -sws 9 -vf crop=720:416:0:82,scale=640:256,harddup "C:\path to\source.vob" -ovc x264 -x264encopts pass=1:qp_constant=22:cabac:deblock:frameref=3:subq=4 -o NUL: -passlogfile "x264_2pass.log"
"C:\path to\mencoder.exe" -ss 00:00:00.400 -frames 1000 -sws 9 -vf crop=720:416:0:82,scale=640:256,harddup "C:\path to\source.vob" -ovc x264 -x264encopts pass=2:bitrate=650:cabac:deblock:frameref=3:subq=5 -of avi -ffourcc VSSH -o output.avi -passlogfile "x264_2pass.log"

you can read up the meaning of all the switches here

i chose the VSSH fourcc to be able to play streams with b-frames with the videosoft decoder (but ffdshow also knows that fourcc)

[akupenguin]

Originally posted by bond
hm, does x264 already offer adaptive quant?

no.

what do you mean exactly with "unaffected" and "anything less is suboptimal quality"?

subq=5 runs the full motion search on all macroblock types. this is implemented.
subq<5 runs part of the motion search algorithm on all block types, then chooses the best type, then finishes the search on just the winner. I haven't implemented the finishing part for B-frames. So subq=1 will use only fullpel motion compensation for B-frames, and subq=3 will use only halfpel.

nope, this also happens with streams not using b-frames (tested it on two different encodes)

I don't see it (MEncoder 1.0pre6, x264r72). Post commandline and samples?

hm, so i assume enabling b-frames, disables 4x4mv? are there any other limitations than the ones you listed atm?

P-frames can still use 4x4mv, but B-frames (so far) only go down to 8x8.

Other limitations:
Non-adaptive direct mode (brute force decision produced about +.1 PSNR in one test encode.)
B-frames aren't kept as references. (No idea how much this would help.)
No weighted prediction (No idea how much this would help, though Ateme might give you an idea. But even JM doesn't do this well, so maybe not.)
Generally non-tuned. I think my fast B_Skip detector is too lenient, but it will take a lot of test encodes and CPU time to tweak it.

also can you plz describe how to enable exactly the different macroblock types via commandline

With my latest patch (applied to mplayer a few minutes ago), the relevent options are 4x4mv (default=off), b8x8mv (default=on), and direct_pred (default=temporal).
Before (i.e. in your test), b8x8 was disabled.

also is it necessary to guess the constant quant for the firstpass or is it possible to use something like pass=1:bitrate=650 instead?

You can use CBR for the 1st pass, but I usually see better results from qp_constant, even if it's significantly off from the 2nd pass bitrate.

to get a better speed is it still possible to use different subq values for 1st and 2nd pass? if yes how big do you think can the difference be (eg for subq=5)?

Yes, that still works, and probably won't ever change. (Maybe when I extend 2pass to do more than ratecontrol.) I've seen good results even from subq=1:no4x4mv:nob8x8mv on the 1st pass. If you want to be conservative, then subq=3:no4x4mv. And theoretically speaking, I would expect that the only option to really matter on the 1st pass would be frameref, since it can affect scenecut detection. Even then, you don't lose too much from 1st pass frameref=1, except in special cases.

also where exactly can i find the latest x264 sources? where do you upload them? mplayer cvs/svn, videolan cvs/svn...?

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

when doing frame-by-frame comparisons, b-frames seem to introduce fluctuating quality (once more details than xvid, once less. i assume depending on whether you look at a b- or i/p-frame)

Really? I see more fluctuation in XviD, which uses quant 2 for P-frames and quant 4 for B-frames. Whereas x264 used a factor of 1.4, which I recently changed to 1.3.

x264: mencoder20041212_Lanczos_Cabac_(no)deblock_alpha-beta:-3,-3_(no)Bvops-2_subq1/5

recommended:
Bvops at most 1 until I finish adaptive decision.
frameref=3 or so on the 2nd pass. (larger numbers help slightly, but not worth the extra time except on anime.)

[Yong]

Originally posted by bond
i just tested celtic_druid's latest athlonxp compile (12/23) and it always crashes here in msvcrt.dll (winme) when encoding with x264 (lavc mpeg4 works fine).
i also tested his 10/26 tbird build (as it was reported to be working correctly) and it indeed works here (so something must be b0rked in x264's code currently)
edit: 12/12 tbird compile works too

i have a pentium3 866mhz (nice, i know )


EDIT: and in case someone didnt realise it till now, its possible to decode avc streams created by x264 (mencoder) with the freely available avc directshow decoder of videosoft (even if the streams are using CABAC, Deblocking and B-Frames (2 in a row) combined) when using the VSSH fourcc in avi!
great stuff!!!

The latest build mplayer2004.12.23P4.7z also crash for me(crash msvcrt.dll), when try to encode video with x264,
i'm on P4 2.4GHz, Windows XP machine,
Now i'm downloading the new mplayer2004.12.28P3.7z, but not sure it can work on my machine or not...

[celtic_druid]

Looks like there is a problem with all the builds from the 23rd and x264 encoding. I will put up some new builds. Will have the patch that akupenguin was talking about, plus x264r73 anyway.

[Yong]

Wow thanks!!!

[celtic_druid]

Ok, new compile seems fine. Think it was a case of an old header. Next issue could be audio output as the cvs appears to be in the middle of a change there. Anyway audio is working fine here both with dsound and win32.

[bond]

new compiles work fine (except pentium4 one, which crashes in mencoder.exe here)

[bond]

ak, could you reproduce the "greenish picture" problem i reported?
the nero decoder also shows that effect

Originally posted by akupenguin
I don't see it (MEncoder 1.0pre6, x264r72). Post commandline and samples?

ok, i used the following commandline on cd's build from today:

mencoder.exe -frames 1000 matrix1.vob -ovc x264 -of avi -ffourcc VSSH -o mencoder.avi

when encoding mencoder always reports "1 duplicate frame(s)!" at the beginning

when opening the file in virtualdub, 999 frames get reported
edit: when using the same commandline, but with "-ss 00:00:00.400 -frames 500 -noskip -sws 9 -vf crop=720:416:0:82,scale=640:256", 500 frames got outputted/reported in vd (so not one too few)

when extracting the video stream from .avi to raw with mpeg4ip's avi2raw tool, i get the warning "1 zero length frames ignored" and "998 video frames written"
on the 500 frames sample i got a "2 zero length frames" -> 498 frames

grab the sample here
edit: added the 500 frames sample

on longer streams i encoded last time (7119 frames), the tool skipped 2 "zero length frames" too (never used b-frames)

[akupenguin]

Originally posted by bond
ak, could you reproduce the "greenish picture" problem i reported?
the nero decoder also shows that effect

No, I don't see that either. (I've tried lavc and JM for decoding.)

ok, i used the following commandline on cd's build from today:
when encoding mencoder always reports "1 duplicate frame(s)!" at the beginning

OK, that's a problem with mencoder's A/V sync algorithm, which is common when encoding from VOBs. It's not related to x264. If you know the source is good, use "-noskip -mc 0". If you need to let mencoder "correct" A/V sync, use "-vf harddup". (I'll add skip-frame encoding to x264 some time to make this more automatic.)

[bond]

so you are sure that there are no "zero length frames" in the two video samples i uploaded, mpeg4ip complains about?

Originally posted by akupenguin
No, I don't see that either. (I've tried lavc and JM for decoding.)

i have uploaded a screenshot of the xvid encode showing the true color of the video, which you can compare to the two samples i linked to in my last post

grab it here

[akupenguin]

Originally posted by bond
so you are sure that there are no "zero length frames" in the two video samples i uploaded, mpeg4ip complains about?

There are zero length frames, it's just that they were added by mencoder, not by x264. The mencoder doc says that these zero frames are no problem in avi, but should be avoided (using harddup) if you're going to remux.

[bond]

by analysing the raw avc streams with mpeg4ips h264.exe tool, i noticed that it seems as if there are always 1 more reference frame signalled than was used: eg if i set only 1 ref frame it says "num_ref_frames: 2", if i set 3 "num_ref_frames: 4", aso...

Originally posted by akupenguin
There are zero length frames, it's just that they were added by mencoder, not by x264. The mencoder doc says that these zero frames are no problem in avi, but should be avoided (using harddup) if you're going to remux.

thx! i used the following cmdl:

"C:\path\mencoder.exe" -ss 00:00:00.400 -noskip -mc 0 -sws 9 -vf crop=720:416:0:82,scale=640:256,harddup "C:\path\matrix1.vob" -ovc x264 -x264encopts pass=1:qp_constant=22:cabac:deblock:deblockalpha=-3:deblockbeta=-3:frameref=3:subq=4 -o NUL: -passlogfile "x264_2pass.log"

(harddup for both passes), but there are still the two zero frames

[akupenguin]

oh, I know what's up: it's the mpeg2 decoder delay. The delay is reduced to 1 frame by using "-vfm ffmpeg" (as opposed to libmpeg2. which also has problems seeking (produces garbage for the next B-frame). I don't know why it's still the default).
I didn't notice this problem in my backups before, because I always go through huffyuv (now ffvhuff), which happens to fix it.