x264 development

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