mencoder+x264

[hellfred]

Originally posted by akupenguin
And why are you using such a tiny rc_buffer_size ?
Because actually i do not know what i am doing after all?
I try to get along with the infos given in mplayer manpage and some very basic knowledge from doom9 guids for encoding MPEG4.
So what do you suggest for rc_buffer_sice (and all the other parameters tuning the rate control)?
Another question where I need your help please.
I do not understand the concept of the options needed for multipass encoding in x264 or the wording of the manpage.
For first pass (analysing complexity of the source frames) i have used
-x264encopts pass=1:qp_constant=22:...
and for the second pass
-x264encopts pass=2:bitrate=450:...
and hoped that in average(!), each set of 24 frame will get 450 kbit (24 frames = one second), the less complex frames sets less bitrate and the more complex frames sets more bitrate. Though reading the manpage again I got some doubts, as only ConstantBitRate is mentioned there:
bitrate=<value>
Sets the bitrate to be used in kbits/second (default: off).
This is required if you want a CBR (constant bitrate) encode.
So what do i have to add after pass=1 and pass=2 for two pass encoding, and what after pass=1 and after first and second pass=3 for three pass encoding?

Hellfred

[akupenguin]

The default rc_buffer_size is 1 second's worth of bits, so you could just leave it alone. But if you do want to specify it, it's measured in kbits, not seconds, so you'd want something around rc_buffer_size=450.

In both CBR and multi-pass, setting rc_buffer_size too small will cause wild fluctuations in quantizer, because even a small error in predicting one frame size will completely empty or fill the buffer. The optimal buffer in my tests was around .5-1 second for CBR, or 1-2 seconds for multi-pass. So I selected a default of 1 second, and you shouldn't have to change it unless you have some special restrictions.

Now, in your case it didn't actuall kill your encode, because x264 recognizes 1kbit as a rediculously small buffer (it's less than the size of one frame), emits a warning message, and uses .5 seconds worth of bits instead.

[hellfred]

I read in the manpage that the default for rc_buffer_sice is just enough bitrate to store the frames of one second of the clip, but i missed that i have to give kbits, not the amount of seconds i want it to store. Stupid me. Any hints about what to specify after pass=1 and pass=2/3? Google does not help me with this problem.

Hellfred

EDIT: This is my first try of a three pass encoding:
#Versuch5
./mencoder test.avi -ovc x64 -x264encopts pass=1:qp_constant=15:fullinter:cabac:deblock:subq=4:keyint=300: \
scenecut=45:frameref=8:deblockalpha=1:deblockbeta=0 \
-nosound -of avi -o out.avi
./mencoder test.avi -ovc x64 -x264encopts pass=3:bitrate=450:qp_min=15:qp_max=51:qcomp=0.8:rc_buffer_size=700: \
fullinter:cabac:deblock:subq=4:keyint=300:scenecut=45:frameref=8: \
deblockalpha=1:deblockbeta=0 -nosound -of avi -o Versuch5_pass2.avi
./mencoder test.avi -ovc x64 -x264encopts pass=3:bitrate=450:qp_min=15:qp_max=51:qcomp=0.8:rc_buffer_size=700: \
fullinter:cabac:deblock:subq=4:keyint=300:scenecut=45:frameref=8: \
deblockalpha=1:deblockbeta=0 -nosound -of avi -o Versuch5_pass3.avi

[akupenguin]

You can save some time by using a faster first pass: nofullinter, subq=3, maybe frameref=4. (I haven't tested exactly what effect a reduced first-pass frameref has on final quality, but it should be ok in 3pass mode.)

Other than that, the optimal scenecut depends on the video, and deblockalpha/deblockbeta are a matter of preference. You'll have to decide for yourself what looks best.

[yaz]

@akupenguin
thx for your help ! amof, what i've found about h264 encoding so far is far not enough to make any reasonable setup in mencoder. maybe, u can answer these too.
- i understand that rc_b_s is set to 1s if bitrate is defined. but how is it set in quality mode (fixed quantizer) ?
- what q do u suggest for the 1st pass ? i tried 5, 10, 15, 20 but i can't see any difference & differences in psnr were also very small (in the range of 0.0x)
- what if only subq=1 is used for 1st pass ? does it affect significantly the 2nd pass ? again, i found not too much difference caused by subq of 1st pass

thx
y

[akupenguin]

rc_b_s affects ratecontrol - the function that modifies quantizers to meet a desired bitrate. In fixed quantizer mode there's no ratecontrol at all, so rc_b_s does nothing.

I recommend using a 1st pass QP about the same as the expected average QP of the final encode. Yes, you'll have to guess. It's probably better to err on the side of lower QP.

Yes, you can probably use much faster options on the 1st pass. In 3 pass mode, you might even get away with leaving out some options on the middle pass. I'm still mostly working on implementing H.264 features, so not so much testing has gone into speedwise optimal options.

[pogo stick]

I am so exited about development of x264! Akupenguin, please, keep your good work! :)

Originally posted by dragongodz
not exactl sure where this should go but since cabac and b frames mentioned in the previous page...

h264.c in ffmpeg just had this

> Allows decoding of most B-type MBs in H.264 with CABAC.
> B_Skip is still unimplemented.

thought some people here may find it of interest. :)
Does it mean that B-frames and CABAC will be correct decodable by mplayer and ffdshow?
And what is B_Skip?

[yaz]

thx for the answers !
Originally posted by akupenguin
I'm still mostly working on implementing H.264 features, so not so much testing has gone into speedwise optimal options. pls, keep on developing ! amof, i'm interested not really in speed but in quality. and it's getting better and better :-)
thx
y

[gotaserena]

slightly OT, but are celtic_druid's builds of mplayer supposed to work "out of the box"? I'm having trouble playing h.264 files with it, both in .avi (wrapped by mencoder itself) and .mp4 (muxed by mp4creator, which changes the fourcc to avc1).

Anybody knows what is going on?

[celtic_druid]

Works fine here. At least with avi files. What exactly is the problem?

[gotaserena]

Thanks, celtic_druid... It's probably me doing smth stupid, but here it goes.

when I play a .avi h.264 file I get errors like
[h264 @ 007A3C38]left block unavailable for requested intra4x4 mode -1 at 0 0
[h264 @ 007A3C38]error while decoding MB 0 0
[h264 @ 007A3C38]concealing errors
and then crashes.

when I try the .mp4 I get these
[h264 @ 007A3C38]error, NO frame 0%
Error while decoding frame!
which keeps going.

The mplayer I compiled in linux works with both files. I'm just compiling CVS with x264 support in cygwin to see if I can repeat the error.

[bond]

Originally posted by gotaserena
muxed by mp4creator, which changes the fourcc to avc1thats the correct behaviour, every h.264 stream has to be marked as "avc1" in .mp4

[Yong]

What's problem with my x264 encoding options?

"F:\mplayer\mencoder.exe" %1 -o "%userprofile%\desktop\%~n1.avi"
-noskip -oac copy -ovc x264 -x264encopts
bitrate=1200:keyint=300:frameref=3:nocabac:bframes=3

Crash mplayer and ffdshow...
Cause by the b-frame?

[akupenguin]

Before anyone can help you, please read the Bug Reporting Guidelines (http://mplayerhq.hu/DOCS/HTML/en/bugreports.html).

As for what's wrong with your options: CBR mode sucks (there's nothing wrong with x264's implementation of CBR, it's just that CBR in general sucks), and bframes don't help yet (this one is x264's fault). But that's not why it crashed.

[Yong]

Originally posted by akupenguin
Before anyone can help you, please read the Bug Reporting Guidelines (http://mplayerhq.hu/DOCS/HTML/en/bugreports.html).

As for what's wrong with your options: CBR mode sucks, and bframes don't help yet. But that's not why it crashed.

Sorry, my english comprenhensive is not good...
I use CBR for testing only ;) .
That's mean you recommend me using the fix quant?
Still can't use b-frame?

OK, i'll try to make the bug report as detail as possible.

[Yong]

What's the meaning by this?
x264 [warning]: rc buffer size 0 too small

It's there have any problem with my x264 encoding setting?
"F:\mplayer\mencoder.exe" %1 -o "%userprofile%\desktop\%~n1.avi"
-noskip -oac copy -ovc x264 -x264encopts keyint=300:frameref=3:deblockalpha=3:
deblockbeta=3:rc_buffer_size=6:rc_init_buffer=6:qp_constant=31

[hellfred]

Originally posted by Yong
What's the meaning by this?
x264 [warning]: rc buffer size 0 too small

It's there have any problem with my x264 encoding setting?
"F:\mplayer\mencoder.exe" %1 -o "%userprofile%\desktop\%~n1.avi"
-noskip -oac copy -ovc x264 -x264encopts keyint=300:frameref=3:deblockalpha=3:
deblockbeta=3:rc_buffer_size=6:rc_init_buffer=6:qp_constant=31
I have made this mistake, too.
In the manpage you can read that the RateControl buffer size will default to a value that represents the amount of memory needed to store one second of the video, so for bitrate of e.g. 350 kbits per second the default equals rc_buffer_size=350. You need to set the kbits per seconds, not an amount of seconds. See akapenguins post above (15 posts earlier in this very same thread, on the third page) for some suggestions.
And by the way, for a one pass encode with fixed quantizizer, setting rate control is not needed. It is usefull for the second and third pass of a 2 pass or 3 pass encode. Read my posts above for some example commandlines for this, they are on the third page of this thread, too, just after akapenguins suggestions for a good rc_buffer_size.
Hellfred

[Yong]

Thanks hellfred, i won't make that mistake again;),
BTW your CLI x264 option is a good reference for me:D

[Yong]

New questions:
Sorry for the OT,
1. How disable video output at two-pass first-pass encoding in mencoder
(like XviD encoding, the first pass video may be large or equal to source video)?

2. It's the MPlayer have an option too raise the apps priority?
mplayer might be too sensitive at windows environment, event a right click can cause the audio or video playback become stuttering.:(

[nexx]

Originally posted by Yong

2. It's the MPlayer have an option too raise the apps priority?
mplayer might be too sensitive at windows environment, event a right click can cause the audio or video playback become stuttering.:(

If you're using a batch file, you can set the program's priority via switches

eg:
start /w /BelowNormal mencoder.exe

the /w means it will wait until it's finished before running the next command

[hellfred]

Originally posted by Yong
New questions:
Sorry for the OT,
1. How disable video output at two-pass first-pass encoding in mencoder
(like XviD encoding, the first pass video may be large or equal to source video)?

2. It's the MPlayer have an option too raise the apps priority?
mplayer might be too sensitive at windows environment, event a right click can cause the audio or video playback become stuttering.:(
I do not have a better answere than nexx for question #2 on win32.
On linux you can set the priority with the nice command
See e.g. this page (http://www.bunkus.org/dvdripping4linux/single/index.html#tc_mplayer_preview1) and man nice.
Now for Question #1. If you encode in any sort of linux/unix like environment, so MSYS or cygwin on Win32, you can put the output in the file /dev/null. /dev/null is like a black hole: everything you write there just vanishes. Performance on linux should be quite well, no idea what it is like on win32. What i have read in the mencoder manpage up to now indicates that there is no way to discard the output for the first pass other than sending it to /dev/null.
mencoder -o /dev/null -oac ...

Hellfred

[Leak]

Originally posted by hellfred
Now for Question #1. If you encode in any sort of linux/unix like environment, so MSYS or cygwin on Win32, you can put the output in the file /dev/null. /dev/null is like a black hole: everything you write there just vanishes. Performance on linux should be quite well, no idea what it is like on win32.

That would be "NUL:", as in "echo foo >NUL:"...

[hellfred]

Thanks for the tip, Leak.
"mencoder -o NUL:" works like a charm
Hellfred

[Yong]

great thanks for you, guys!!
@hellfred:
I have cygwin install on my computer, but dunno how to use...
(ok ok, enough off-topic already... Stop here);)

[DeepDVD]

It's kinda strange but all those new experimental codecs coming up and getting more stable from time to time doesn't have the option of VBR encoding. I can't really compare 2 clips without using the same kind of handling the bitrate... It's very frustrating ... :angry:

[RadicalEd]

Is it just me, or is celtic's 10/22 build not outputting files? :O 10/27 doesn't have x264 enabled and I can't test 10/31 due to lame processor. Still trying to get mingw to compile it myself so I can cross-check

[akupenguin]

@DeepDVD:
It's not so strange when you consider that the optimal ratecontrol algorithm depends on the characteristics of the compressor, and a suboptimal ratecontrol is no better than constant quant for a quality per filesize tradeoff. You can't just paste in another ratecontroller. So it's both easier and more logical to make it first compress well at constant quant, and only worry about ABR when the low-level algorithms have stabilized.
That said, if you're complaining in this thread, you're probably using ffdshow, and just haven't noticed that it has a weird interface for x264's 2pass mode.

[celtic_druid]

MEncoder dev-CVS-041026-20:10-3.4.2 (C) 2000-2004 MPlayer Team
Available codecs:
copy - frame copy, without re-encoding. Doesn't work with filters.
frameno - special audio-only file for 3-pass encoding, see DOCS.
raw - uncompressed video. Use fourcc option to set format explicitly.
nuv - nuppel video
lavc - libavcodec codecs - best quality!
vfw - VfW DLLs, currently only AVID is supported.
qtvideo - QuickTime DLLs, currently only SVQ1/3 are supported.
xvid - XviD encoding
x264 - H.264 encoding

Not enabled?

Just tested the 26/10 and the 22/10 tbird builds (on a athlon 800) and they both seem to work fine. Only re-encoded a 10sec avi clip. -ovc x264 -oac copy -o out.avi.

[RadicalEd]

Hm... faulty bug report. I'm not sure where the no-x264 build of mencoder I was using came from. No output must have been a problem with my settings, because the simple -ovc x264 -o out.avi works alright...
Sorry bout that :/

[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 :D )


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!!! :)

[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? :confused:

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 :D

[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 (http://mplayerhq.hu/DOCS/man/en/mplayer.1.html)

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 :D )


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.aviwhen 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 (http://mp4menu.sourceforge.net/download/sample.zip)
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 (http://mp4menu.sourceforge.net/download/sample.png)

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