x264 development

[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