x264 development

[Sharktooth]

didnt work for me. maybe i'll try again when i have some time.

[Leak]

Originally posted by Sharktooth
didnt work for me. maybe i'll try again when i have some time.

Works like a charm here; and if you want to build directly under Linux just install coLinux (http://www.colinux.org/) (which is basically a Linux kernel running as a Windows process) and use the X server under windows as a display...

np: Primal Scream - Stuka (Two Lone Swordsmen Remix) (Two Lone Swordsmen - Peppered With Spastic Magic)

[Sharktooth]

well, im redownloading cygwin with X11 and i will try re-building x264.

[nm]

For those unfamiliar with X11, note that X is not just a graphics library, but an entire client-server architecture in which you have to run the server process, X separately. I suppose the Cygwin X project has basic usage instructions somewhere, so be sure to read the documentation. Also try some X applications like xcalc that come with the server (maybe in a separate tools-package, haven't checked myself). If they don't work, nothing else will either.

[Sharktooth]

I managed to compile a win32 build with -visualize enabled but it's useless unless you have cygwin with X11 installed, so i'll keep it disabled...

[Sirber]

Questions:

1) ./configure doesn't like -ffastmath.
2) Can I set -march from ./configure cmdline?

[CREXbzh]

Originally posted by Sirber
Questions:

1) ./configure doesn't like -ffastmath.
2) Can I set -march from ./configure cmdline?

You can edit config.mak after ./configure, that sure works.

[akupenguin]

configure --extra-cflags="-march=..."

[Sirber]

ok. I'll try. Thanks! :D

[Sharktooth]

-ffast-math doesnt work with SSE.

[LigH]

So, revision 237 ff has "zones" now. :thanks:

Unfortunately, not yet in the VfW GUI. -- How long may it take to redesign the dialog?

[Sharktooth]

Im working on the vfw gui, but an average of 5mins/day coz am really busy.
So any help is welcome.

[TNM]

I'm sorry if this question was asked before but for x264vfw, what happen if i set the deblocking filter strength to negative values?

Also about the max and min IDR-frame interval, do they work the same way as xvid's which mean i need to set them according to my vid's fps value?

[CREXbzh]

Originally posted by TNM
I'm sorry if this question was asked before but for x264vfw, what happen if i set the deblocking filter strength to negative values?

Also about the max and min IDR-frame interval, do they work the same way as xvid's which mean i need to set them according to my vid's fps value?

For the deblocking filter, the way I understand it: it has a tendency to wash out some details a bit too much, so if you set it to a negative value, you'll sort of "get back some details".

Please read this doc to get more informations: http://www.mplayerhq.hu/DOCS/HTML/en/menc-feat-x264.html

Regarding max/min IDR-frame, I don't know.

[snacky]

Originally posted by CREXbzh
[B]For the deblocking filter, the way I understand it: it has a tendency to wash out some details a bit too much, so if you set it to a negative value, you'll sort of "get back some details".
I don't agree with this. I think you will see more artifacts than details. You will also see a PSNR decrease in most cases. However I will admit that in pictures with high spatial frequency, detail and artifacts may look similar.
Please read this doc to get more informations: http://www.mplayerhq.hu/DOCS/HTML/en/menc-feat-x264.html
I'd like to point out that this guide argues AGAINST weakening the deblocking filter. The guide suggests that it would be better to conceal artifacts by adding a small amount of noise in playback.

[CREXbzh]

Originally posted by snacky
I don't agree with this. I think you will see more artifacts than details. You will also see a PSNR decrease in most cases. However I will admit that in pictures with high spatial frequency, detail and artifacts may look similar.

I'd like to point out that this guide argues AGAINST weakening the deblocking filter. The guide suggests that it would be better to conceal artifacts by adding a small amount of noise in playback.
Yeah, I did read the your guide (which is the link I gave). I'd just happends that TNM was asking "what happends if the deblocking filter strength to negative values", and you explained it quite well... :)

[Zero1]

Nice bit of a guide there, x264 could do with some more docs like that ;)

While I'm here, can anyone briefly explain --b-bias, I've read in the CLI that it "Influences how often B-frames are used" but as for choosing a value, I have no idea what would be a good realistic value that wouldn't be detrimental to the quality. Say for instance I was using 3 b-frames and b-pryamid, would setting b-bias to 3 be wise?

With regard to the keyint and minkeyint, it would seem logical to me that you do base these on the framerate of your source, just like you would in XviD. I also changed the --scenecut from 40 to 48 (with my source being 23.976 fps), though I'll admit I haven't checked yet to see if it has a good or bad effect on the quality. Bad me :sly:

[bond]

if you have doubts, the best would be to leave the options at default i would say :)

[el divx]

@ x264 devs: When will support for the baseline, main, high & extended profile features that are currently only accessible through cli be added to vfw?

[bond]

@ x264 devs: When will support for the baseline, main, high & extended profile features that are currently only accessible through cli be added to vfw?
all you vfw/avi loving nerds should have a look at the x264 encoder included in ffdshow (yeah it offers a vfw x264 encoder too), it seems to offer as good as all options of x264 ;)

[Doom9]

the core developers are not even workign on the VfW.. so volunteers would obviously be welcome ;)

[celtic_druid]

I added AR (pretty much copy/paste from GUI) just now to VfW. Tested and working here.

[Sirber]

Cool! Thanks!

Could you add also new 8x8 options? :D

[celtic_druid]

I'll see what I can do.

Some other missing options would be:
scene cut threshold
bframe bias
chroma me
chroma qp offset
vbv max bitrate
vbv buffer size
Initial VBV buffer occupancy
min quant
max quant
quant step
Ratecontrol equation
cplxblur
qblur
me method
me range
idc level

and zones.

Ok, I8X8 and 8X8 DCT added. But let me see if I got this right... I8X8 requires 8x8 DCT. I8X8 is enable by default, but 8x8DCT isn't?

Someone want to test this?
http://mirror05.x264.nl/celtic_druid/test/x264vfw.7z

Didn't waste time arranging stuff as it is all going to need re-arranging anyway to fit other options in.

[bob0r]

I'll see what I can do.

..

Ok, I8X8 and 8X8 DCT added. But let me see if I got this right... I8X8 requires 8x8 DCT. I8X8 is enable by default, but 8x8DCT isn't?

Someone want to test this?
http://mirror05.x264.nl/celtic_druid/test/x264vfw.7z

Didn't waste time arranging stuff as it is all going to need re-arranging anyway to fit other options in.

I disabled 8x8dct, you ask us to test what? if it encodes? if it plays back?
I am now encoding default settings + 8x8dct disabled.

1 pass ABR @ 800kbps

[Doom9]

I'd strongly suggest not adding the rc equation as only codec developer know what it does anyway. there's too much potential to screw up in this area.

[bond]

about vbv and levels:
it would rock if the gui would let the user choose profiles and levels, like xvid does it, and automatically adjust the vbv and options allowed to set according to that (+ an unrestricted option)

[Revgen]

I'll see what I can do.


Ok, I8X8 and 8X8 DCT added. But let me see if I got this right... I8X8 requires 8x8 DCT. I8X8 is enable by default, but 8x8DCT isn't?

Someone want to test this?
http://mirror05.x264.nl/celtic_druid/test/x264vfw.7z



I replaced the x264vfw.dll in my ..Windows/system32/ folder with yours. And encoded a file I previously encoded with sharktooth's rev239 build.

The clip is a Garfield and Friends cartoon encoded at 720x480.

Both clips use the same settings except for the 8x8DCT and 8X8i settings included in your .dll

Whats strange is that I was able to play the HP clip in the 2005-05-10 version of your version of FFDshow.

I installed the new June version afterwards and both played fine in that too.


I also can't tell the difference both clips. They both look good.

It might be because the the resolution is too low and because cartoons don't carry as much detail as a motion picture.


I'm going to try and test and resize some 3 Stooges shorts and see if there is a difference.


UPDATE:

I encoded two ivtc'd three stooges clips at 1440x960 1600kbs which were resized from a 720x480 source.

I couldn't notice a difference between the HP one and the regular one.

[Sagittaire]

bug with 8x8dct: frame 29 with this sample (http://multimediacom.free.fr/Video/bug.mp4)

x264.exe --bframe 3 --8x8dct --ref 5 --filter 0:0 --bitrate 896 --pass 1 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.40 --analyse "all" --weightb --me "umh" --subme 5 --progress -o NUL Encodage.avs
x264.exe --bframe 3 --8x8dct --ref 5 --filter 0:0 --bitrate 896 --pass 3 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.40 --analyse "all" --weightb --me "umh" --subme 5 --progress -o NUL Encodage.avs
x264.exe --bframe 3 --8x8dct --ref 5 --filter 0:0 --bitrate 896 --pass 3 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.40 --analyse "all" --weightb --me "umh" --subme 5 --progress -o x264HP-896.mp4 Encodage.avs

but not with this command line (different bitrate: 447 vs 946)

x264.exe --bframe 3 --8x8dct --ref 5 --filter 0:0 --bitrate 447 --pass 1 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.40 --analyse "all" --weightb --me "umh" --subme 5 --progress -o NUL Encodage.avs
x264.exe --bframe 3 --8x8dct --ref 5 --filter 0:0 --bitrate 447 --pass 3 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.40 --analyse "all" --weightb --me "umh" --subme 5 --progress -o NUL Encodage.avs
x264.exe --bframe 3 --8x8dct --ref 5 --filter 0:0 --bitrate 447 --pass 3 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.40 --analyse "all" --weightb --me "umh" --subme 5 --progress -o x264HP-447.mp4 Encodage.avs

[bond]

bug with 8x8dct: frame 29 with this sample (http://multimediacom.free.fr/Video/bug.mp4)
no problem here playing that file with haali + ffdshow, cant you be more specific?

[Sharktooth]

He means this:
http://www.webalice.it/f.corriga/misc/bug.jpg

Btw i decoded it with Nero decoder. FFDShow can decode it without problems.
Maybe the bug is in nero...

[Manao]

With ateme's decoder, it's wrong too ( though the wrong frame is replaced by a surrounding one )

[dinolib2]

Here with mpc, haalis and latest CD ffdshow, plays fine...

[Manao]

Shartooth, bond, dinolib : nero and ateme's decoders are different, and both have problems decoding that clip. Though a test with the JM would be the most efficient way to find the culprit, it is more than likely that the fault lies in x264 / in gpac.

[Sharktooth]

I will post an updated build with the latest GPAC (updated today).

[Sagittaire]

I will post an updated build with the latest GPAC (updated today).

this last build work perfectly (x264cli 253D + ffdshowdec 06/06/05) in my test for all situation (8x8dct, multi-pref, bref, multi-bframe and combinaisons)

very good job ... :)

[bobololo]

He means this:
http://www.webalice.it/f.corriga/misc/bug.jpg

Btw i decoded it with Nero decoder. FFDShow can decode it without problems.
Maybe the bug is in nero...

This stream appears to be broken. Decoding with the JM (9.6) I got a segfault at picture 29, mb 103. Something seems to be wrong with the reference index.

[Sagittaire]

other (old) problem:
bref + 16 pref playback is good now with ffdshow but not with nero dec.

you want bug: I can to find it ... if you want ... lol

[Sharktooth]

Since i will be at home for some days i decided to restart working on the x264 vfw gui (i re-started from the x264gui by virus):
http://www.webalice.it/f.corriga/misc/gui.png
Advanced options are read from a .xml file so it's easier to update.
The .xml file contains the option name, list of values, registry key, etc...
So when a new functionality is added to the core, you just need to update the .xml file to have it in vfw too.
Well, i hope to finish it soon.

[akupenguin]

bug with 8x8dct: frame 29 with this sample (http://multimediacom.free.fr/Video/bug.mp4)
fixed.

[bob0r]

fixed.

Does this mean ffdshow (libavcodec) needs updating again too?

I just did an encode with build 254
-Latest gpac
-Latest ffdshow
-Latest matroskasplitter

x264 build 254 crashes again.

If we indeed need a new libavcodec, i hope celtic_druid is still here tomorrow!

[Sagittaire]

you want bug ... ???

My HPII trailers and the "warner bros" logo is very hard for encoder ... lol

no bug with x264cli rev 253D + ffdshow 06/06/05 but bug with x264cli rev 253D + last nero AVC dec

bug 3: (http://multimediacom.free.fr/Video/bug3.mp4) problem with bref + multi-pref
x264.exe --bframe 3 --b-pyramid --ref 16 --filter 0:0 --bitrate 447 --pass 1 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.40 --analyse "all" --weightb --me "umh" --subme 5 --progress -o NUL Encodage.avs
x264.exe --bframe 3 --b-pyramid --ref 16 --filter 0:0 --bitrate 447 --pass 3 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.40 --analyse "all" --weightb --me "umh" --subme 5 --progress -o NUL Encodage.avs
x264.exe --bframe 3 --b-pyramid --ref 16 --filter 0:0 --bitrate 447 --pass 3 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.40 --analyse "all" --weightb --me "umh" --subme 5 --progress -o x264MP-447.mp4 Encodage.avs

bug 4: (http://multimediacom.free.fr/Video/bug4.mp4) always problem with bref + multi-pref
x264.exe --bframe 3 --b-pyramid --ref 16 --filter 0:0 --bitrate 896 --pass 1 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.40 --analyse "all" --weightb --me "umh" --subme 5 --progress -o NUL Encodage.avs
x264.exe --bframe 3 --b-pyramid --ref 16 --filter 0:0 --bitrate 896 --pass 3 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.40 --analyse "all" --weightb --me "umh" --subme 5 --progress -o NUL Encodage.avs
x264.exe --bframe 3 --b-pyramid --ref 16 --filter 0:0 --bitrate 896 --pass 3 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.40 --analyse "all" --weightb --me "umh" --subme 5 --progress -o x264MP-896.mp4 Encodage.avs


bug 1: (http://multimediacom.free.fr/Video/bug1.mp4) always problem with bref + multi-pref
x264.exe --bframe 3 --b-pyramid --8x8dct --ref 16 --filter 0:0 --bitrate 447 --pass 1 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.40 --analyse "all" --weightb --me "umh" --subme 5 --progress -o NUL Encodage.avs
x264.exe --bframe 3 --b-pyramid --8x8dct --ref 16 --filter 0:0 --bitrate 447 --pass 3 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.40 --analyse "all" --weightb --me "umh" --subme 5 --progress -o NUL Encodage.avs
x264.exe --bframe 3 --b-pyramid --8x8dct --ref 16 --filter 0:0 --bitrate 447 --pass 3 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.40 --analyse "all" --weightb --me "umh" --subme 5 --progress -o x264HP-447.mp4 Encodage.avs


bug 2: (http://multimediacom.free.fr/Video/bug2.mp4) always problem with bref + multi-pref and another frame 29 bug
x264.exe --bframe 3 --b-pyramid --8x8dct --ref 16 --filter 0:0 --bitrate 896 --pass 1 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.40 --analyse "all" --weightb --me "umh" --subme 5 --progress -o NUL Encodage.avs
x264.exe --bframe 3 --b-pyramid --8x8dct --ref 16 --filter 0:0 --bitrate 896 --pass 3 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.40 --analyse "all" --weightb --me "umh" --subme 5 --progress -o NUL Encodage.avs
x264.exe --bframe 3 --b-pyramid --8x8dct --ref 16 --filter 0:0 --bitrate 896 --pass 3 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.40 --analyse "all" --weightb --me "umh" --subme 5 --progress -o x264HP-896.mp4 Encodage.avs

[bob0r]

@Sagittaire
Can you also try if the same bugs still exist with revision 254?
Because maybe the typo fix in 254 fixes more than just 1 bug.

You may have a problem with playback of 254, lets just hope we can fetch an update before all coders are on summer timeout :scared:

[celtic_druid]

Fixed the VfW. DCT8x8 wasn't getting enabled.

[Tommy Carrot]

What is the advantage of "umhex" motion estimation method over the default "hexagon" method? I thought that it might be faster, but apparently it's the contrary, and i cannot really notice any quality improvement when i'm using it.

[Sharktooth]

Uhm... i think there are still some problems with x264 and 8x8 stuff.

http://www.aziendeassociate.it/temp/hp2-x264_8x8-900.avi

watch it with ffdshow and nero...

[Sagittaire]

this "warner bros" logo is very very hard for x264 ... lol

[Revgen]

Fixed the VfW. DCT8x8 wasn't getting enabled.

<SHORT STORY>
I tested the new VfW.

High Profile seems to be working now.

<LONG STORY>

I resized and reencoded my 720x480 3 Stooges clips that I mentioned earlier at 1600kbps and 1440x960 resolution. The HP settings now take longer to encode than the SP. They both took the same amount of time with yesterdays version.

The difference between the SP and HP clips are very small. I have to look at at individual frames in Virtual Dub to see what details are preserved in the HP settings. The HP does preserve details but IMHO isn't worth the extra time to encode.

Part of the reason for this may be that my 3 stooges clips come from a low resolution source, and HP may work better with original HD content.

I'm going to try downloading some non-DRM WMV HD trailers from the Microsoft site and see if I can't get better results.

[akupenguin]

no bug with x264cli rev 253D + ffdshow 06/06/05 but bug with x264cli rev 253D + last nero AVC dec
OK, one of the SPS values was bad, and ffdshow was OK since it ignored that value.

Uhm... i think there are still some problems with x264 and 8x8 stuff.
Both lavc and JM die on the last frame of that clip. Is it a coincidence that the error is there, or can you create a shorter clip with the same error, or are you complaining of something else?

EDIT: oops, truncated download. No, I don't see any errors with either lavc or JM, and seeking works properly in MPlayer.

I resized and reencoded my 720x480 3 Stooges clips that I mentioned earlier at 1600kbps and 1440x960 resolution.
duh. If you upsize by a factor of 2, then there aren't any details.

What is the advantage of "umhex" motion estimation method over the default "hexagon" method? I thought that it might be faster, but apparently it's the contrary, and i cannot really notice any quality improvement when i'm using it.
It is higher quality. On an average movie, I see only something like +.1 PSNR (which is why it isn't the default), but some high-motion clips (e.g. bus.cif) get huge savings. If done optimally, umhex would be only a little slower than simple hex. x264's implementation isn't optimal.

[Sharktooth]

I'll try to recreate with another clip. Btw if you seek forward the video starts to playback normally... then suddenly it gets distorted until the next keyframe.