x264 development

[wyti]

http://repo.or.cz/w/x264/x264-p-frames.git?a=shortlog;h=refs/heads/gsoc

it's not a patch but a git you will find here all you need (a complete x264 with weighted p

[moviefan]

OK, sound good and easy to do. How about the quality of the modification? Is it reliable?

Edit: Sorry, I just noticed the website on videolan.org about the weightp patch.

[Snake91]

but here is the build for win32 fprofiled build if interested : http://www.mediafire.com/download.php?dtdxzk4d0nl (note : mp4 and mkv oupture not activated, it can only produce elementary streams (you will have to mux) but avisynth input enabled)
It uses only one core and if I forced with --threads 6 x264 turns with the warning:"not compiled with pthread support" . May you compile a test-build with pthread? :)

[XhmikosR]

./configure --extra-cflags="-march=core2"
Platform: X86
System: MINGW
asm: yes
avis input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no

You can run 'make' or 'make fprofiled' now.

make fprofiled VIDS="SOCCER_352x288_30_orig_02.yuv"
GCC 4.4.1, unpatched (despite the "M")

Download here (http://www.mediafire.com/?zzqktjoowot). (Built on 11/01/2009)

[Snake91]

thx a lot

[CpT]

When using the above build is it automatically on or is there a command requirement to activate it?

And Thanks for the build btw :thanks:

[RainyDog]

So, am I right in thinking that if I download JEEB's 64bit patched 1318 build from here http://jeeb.fiveforty.jp/x264/1309_x64/x264.exe, weightp will be on as default? Thanks.

[thewebchat]

@CpT: When I tried, it printed something like [Weighted P frames: 40.9%] regardless of if I actually specified --weightp. Both modes seem to do the same thing (?).

@RainyDog: No.

[CpT]

-thewebchat
Ahh yep just saw it in the output log.

I take it the 2 pics from the previous page were done with mbtree on?

[RainyDog]

@CpT: When I tried, it printed something like [Weighted P frames: 40.9%] regardless of if I actually specified --weightp. Both modes seem to do the same thing (?).

@RainyDog: No.

Ok, thanks. Will it be on if I specify --weightp?

[RainyDog]

I take it the 2 pics from the previous page were done with mbtree on?

I think they were done with mbtree turned off if I'm interpreting his post near the top of the previous page correctly.

[XhmikosR]

Why don't you run x264M.x86.core2.pframes --fullhelp to see what options are available?

[thewebchat]

The message from --fullhelp doesn't indicate it, but the default value of --weightp is 2, and 0 can be used to disable it. It does not seem to have a significant impact on speed (maybe ~10%).


From x264.h:
98 #define X264_WEIGHTP_NONE 0
99 #define X264_WEIGHTP_BLIND 1
100 #define X264_WEIGHTP_SMART 2

From common.c defaults declaration:
139 param->analyse.i_weighted_pred = X264_WEIGHTP_SMART;

[Chengbin]

-- weightp 3 is available too.

[thewebchat]

No, it's not.

11 days ago Dylan Yudaken remove kmeans

[CpT]

Yea I can't tell a diff between weightp 1 and 2.

weightp 0 is slightly faster but its such a little difference its hardly noticeable. I can't wait for the full commit wewt!

[moviefan]

If I compile from this GIT: http://repo.or.cz/w/x264/x264-p-frames.git, is weightp enabled by default and in case which weightp option is enabled? (1 or 2?) There is no entry in the --fullhelp about the --weigthp option.

[XhmikosR]

The answer is 4 posts above. If you want an unpatched compiled build, you can try this (http://www.mediafire.com/?zzqktjoowot) (built 11/01/2009).

[shon3i]

Can somebody compile last with weightp, nalhrd r16, and bugmaster AQmod, to test what is best for fades?

[moviefan]

Do you want it fprofiled or is it fine without for testing purposes?

[XhmikosR]

If you give me the links to nalhdr16 and AQmod I could do it.

[moviefan]

http://komisar.gin.by/x.patch/BugMaster/20090926/x264_AQ2mod.diff (I guess)
http://h264enc.sourceforge.net/x264_hrd_pd_interlace.16_r1301.diff

[XhmikosR]

x264 patched built from http://repo.or.cz/w/x264/x264-p-frames.git
./configure --extra-cflags="-march=core2"
Platform: X86
System: MINGW
asm: yes
avis input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no

You can run 'make' or 'make fprofiled' now.

make fprofiled VIDS="SOCCER_352x288_30_orig_02.yuv"
GCC 4.4.1, patched with:

AQ2Mod (http://komisar.gin.by/x.patch/BugMaster/20090926/x264_AQ2mod.diff)
HDR_PD_interlace.16_r1301 (http://komisar.gin.by/x.patch/last.used/x264_hrd_pd_interlace.16_r1301.diff)
x264_win_zone_parse_fix_06


Download patched build here (http://www.mediafire.com/?3yzg1jfmgmg). (Built on 11/01/2009)

Download unpatched build here (http://www.mediafire.com/?zzqktjoowot). (Built on 11/01/2009)

[moviefan]

@XhmikosR: When you look at the compile log in the terminal while compiling, do you get a lot of warnings about dereferencing pointers etc.? I get very similar information like in this post: http://forum.doom9.org/showthread.php?p=1310293#post1310293. I read through the thread, but I couldn't find a reply concerning the warnings...

[XhmikosR]

Yes, lots of warnings. But I always get them since I can remember. There was recently a post by Dark Shikari in which he explained it a little, but I can't find it.

[moviefan]

OK, good to know as I did my first own build of x264 yesterday and got confused by the warnings... However if this is a known "issue" and my build works fine despite warnings, I am relieved everything is as expected.

[LoRd_MuldeR]

Yes, GCC 4.x.x throws hundreds of warning when compiling x264. That's well known. As far as I can tell, you can safely ignore them...

[thewebchat]

There were just a few updates to mc-a.asm up at the GIT tree. Anyone want to try building on Win64 again? Also, I'm pretty sure that AQ2Mod 1) sucks and 2) is definitely useless with weightp (this was tested).

[shon3i]

Also, I'm pretty sure that AQ2Mod 1) sucks and 2) is definitely useless with weightp (this was tested). I am testing right now. Anyway AQmod show help in other cases too, like dark frames etc.

[Arshad07]

Why am i getting this error using latest x264?

http://i37.tinypic.com/r93hpk.jpg

[shon3i]

MeGUI can't handle x264 propertly. So don't use MeGUI for x264 until new version is out.

[J_Darnley]

Paste the command line in future. You have not used a correct command line, the argument for --b-pyramid is "--direct". I would say MeGUI needs updating to work with the latest B-pyramid commit.

[XhmikosR]

Why am i getting this error using latest x264?

http://i37.tinypic.com/r93hpk.jpg

Because you are using a non-latest MeGUI build. But anyway, latest MeGUI has lots of bugs. Try another GUI until MeGUI is fixed.

EDIT: lol I'm very slow:p

[moviefan]

Is there any explanation for the following: I encoded a 1080p clip with --vbv-maxrate 15000 --vbv-bufsize 30000 --keyint 48 --min-keyint 2 and when I analyze the output stream with Elecard Stream Eye, the info box shows

bitrate declared : 15 000 000
--------------------------------------------
real max : 17 844 411
real avg : 8 717 175
real min : 3 532 232


real max is greater than --vbv-maxrate so that Blu-ray compliancy is broken considering the large GOP I used, right? I encoded with the latest build.

[shon3i]

real max is greater than --vbv-maxrate so that Blu-ray compliancy is broken considering the large GOP I used, right? I encoded with the latest build.No that is because you use --vbv-bufsize 30000. Highest peak is 30mbps, everything is fine.

[moviefan]

So please help me understand: what does --vbv-maxrate do then? I thought it limits the max bitrate to 15000 kbps.

[LoRd_MuldeR]

So please help me understand: what does --vbv-maxrate do then? I thought it limits the max bitrate to 15000 kbps.

This has been explained a million times! The "--vbv-maxrate" option doesn't have a meaning without the "--vbv-bufsize" option specified as well.

And it doesn't directly limit the maximum bitrate of the video. It limits the maximum rate at which data can enter the buffer in the VBV model.

:search:

[juGGaKNot]

The answer is 4 posts above. If you want an unpatched compiled build, you can try this (http://www.mediafire.com/?zzqktjoowot) (built 11/01/2009).

Looks great, better than aq2mod at 1.0:1.0 and faster than without ( weird no ? ) tried mode 2.

Why is it not done yet ? what specific problems i want to know, i'm thinking of using it now and not waiting for the final release.

I am testing right now. Anyway AQmod show help in other cases too, like dark frames etc.

It helps a bit ( not as much as a weightp build ) but ratefactor is bigger by 2 on my source ( 20 compared to 18 )

[thewebchat]

Uh, maybe it's not done yet because it's not done? I'm pretty sure that it's not working 100% optimal, as I've found some fades to white are actually worse now.

Edit: Crossfades too.

[Japhsoncross]

i tested several revisions of weightp with several kinds of fades, it's really exciting.
i think crossfades are hard to distinguish between motion and fade.

[G_M_C]

Peeps, just pe patient; It'll get there :)

Pengvado review status = 1

:p

[kemuri-_9]

that was only pengvado/akupenguin's first review, there are more to come.
also weightp 2 is broken afaik.

but it is coming along.

[moviefan]

Is weightp only broken in terms of the visual output and/or in terms of spec compliancy?

[kemuri-_9]

the issues i recall being stated surrounding weightp being broken (haven't seen any confirmation of fixes) were

A) 2pass encoding does not work to a miss constructed check under some situations which i don't recall offhand (x264 errors out and doesn't start processing, so you'll know it if you come across it).
B) weightp 2 triggers an incredibly large number of scenecuts (when scenecut is active) which will cause a quality drop.

on a side note, this email (http://mailman.videolan.org/pipermail/x264-devel/2009-November/006502.html) is relevant.
though it was stated as 'few days' in above email, pengvado/akupenguin is now on vacation for a while
and weightp will not commit until it has his full approval.

[LoRd_MuldeR]

CoreAVC broken with "weight-p" in default mode. D'oh! Hope they get the fix out very soon :D

[Snake91]

x264+pframes doesn't give any error when compiling in 64bit mode now:)

[shon3i]

So that mean, can also have complication with standalone devices, similar like b-pyramid?I have no issues with Ateme's weightp

[G_M_C]

Woot:
Multiple additions / fixes per day on the weight-p/GSOC page. Looks like Dylan Yudaken is flying now. Amazing stuff, I wish him much success and good luck for getting it done :)

[juGGaKNot]

http://mirror01.x264.nl/x264/revision1330/x264.exe

x264.exe --preset veryslow --level 3.2 --ref 5 --min-keyint 30 --keyint 300 --bframes 3 --b-pyramid normal --merange 32 --sar 1:1 --aud

http://i286.photobucket.com/albums/ll105/juGGaKNot4cs/th_1330error.png (http://s286.photobucket.com/albums/ll105/juGGaKNot4cs/?action=view&current=1330error.png)

cabac=1 / ref=5 / deblock=1:0:0 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / psy_rd=1.0:0.0 / mixed_ref=1 / me_range=32 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / chroma_qp_offset=-2 / threads=3 / nr=0 / decimate=1 / mbaff=0 / constrained_intra=0 / bframes=3 / b_pyramid=0 / b_adapt=2 / b_bias=0 / direct=3 / wpredb=1 / wpredp=2 / keyint=300 / keyint_min=30 / scenecut=40 / rc_lookahead=60 / rc=2pass / mbtree=1 / bitrate=4300 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / aq=1:1.00

[Audionut]

With my unpatched build,

--tune grain --crf 18 --keyint 240 --min-keyint 24 -o

No problems here so far, 125000/158075 frames.

win7 64bit - q6600.