x264 development

[azsd]

Hi,celtic_druid

follow your site's http://celticdruid.no-ip.com/xvid/
I click the mplayer/mencoder link and only get some mplayer binarary listed to feb 22

does I visited a wrong page?

[Neo Neko]

Originally posted by azsd
try this place:

http://oss.netfarm.it/mplayer-win32.php

latest mencoder build tagged as

http://oss.netfarm.it/mplayer/builds/mencoder-p4-cvs-20050225.zip

mmm,can't find who complied these binarys.

Sticky says ...... sherpya. ;)

Originally posted by azsd
Hi,celtic_druid

follow your site's http://celticdruid.no-ip.com/xvid/
I click the mplayer/mencoder link and only get some mplayer binarary listed to feb 22

does I visited a wrong page?

No you are basically on the right page. He is doing compiles. But apparently they are not getting mirrored. Cause 22nd is the last one I have seen there for a long time.

[Wolfor]

Is anybody developing the High (FRext) profile? And where can I find streams for testing decoder?

[bond]

Originally posted by Wolfor
Is anybody developing the High (FRext) profile? And where can I find streams for testing decoder? encode some yourself with the reference encoder

[Wolfor]

It's a bad way.. Because JM 9.3 is a very slow.. And I want to test alternative stream.
I have many questions about (JVT-L047d9) and (JVT-G050r1) documents..
May I asked? Or it's another subject.

[Doom9]

I have many questions about (JVT-L047d9) and (JVT-G050r1) documents..
May I asked? Or it's another subject.This line of questions doesn't fit the x264 thread (x264 is more or less a main profile AVC encoder)

[lithoc]

Does anyone try compile x264 using GCC 4.0 cvs?
I heard there's a lot of improvement made to this compier.
Anywhere I can get those binaries?

Thanks in advance

[baer999]

2 days without a new version of x264... I can't imagine this. What will be improved in the next versions ?

[Sirber]

Originally posted by lithoc
Does anyone try compile x264 using GCC 4.0 cvs?
I heard there's a lot of improvement made to this compier.
Anywhere I can get those binaries?

Thanks in advance What kind of improvements?

[ak]

From quicky test, gcc 4.0 tad slower and produces lower psnr (same cflags/encoding settings) than 3.4 series.

Here's some binaries (cli and vfw, r146): http://4nykey.nm.ru/misc/x264_gcc40.7z

[len0x]

Originally posted by baer999
2 days without a new version of x264...

Rev 146 is out for quite a while (not in the sticky thread though). Very nice speedup of the first pass :)

[lithoc]

Originally posted by Sirber
What kind of improvements?

According to changelog it says:

The tree ssa branch has been merged. This merge has brought in a completely new optimization framework based on a higher level intermediate representation than the existing RTL representation. Numerous new code transformations based on the new framework are available in GCC 4.0, including:

* Scalar replacement of aggregates
* Constant propagation
* Value range propagation
* Partial redundancy elimination
* Load and store motion
* Strength reduction
* Dead store elimination
* Dead and unreachable code elimination
* Autovectorization
* Loop interchange
* Tail recursion by accumulation

[lithoc]

Is there any way that I can obtain the latest build?
I've look around in variuos places, no sign of r146

Thanks

[Leo 69]

Yes I'm also anxious to get rev 146 build. Where is it? I need to recode some stuff tonight. Preferably with the cutting-edge encoder :)

[celtic_druid]

http://rapidshare.de/files/743270/X264VfW.revision146.exe.html

[niamh]

also check out the daily build thread, there's a good surprise in store :)

[Leo 69]

From the rev.145 changelog :

(fast1stpass was slower than non-fast)

They've fixed it, at last :D

[lithoc]

Got it
Thanks a lot!!!

[Sharktooth]

Sorry guys, i have no internet connection until the weekend... the reason is ... EXCESS OF SNOW (no, not the codec...).

[bond]

Originally posted by Sharktooth
Sorry guys, i have no internet connection until the weekend... the reason is ... EXCESS OF SNOW (no, not the codec...). cocaine? :p

[len0x]

Originally posted by bond
cocaine? :p

That would be blow :p

[thed33p]

(+5, Funny)

I've been lurking for a long while now.

LUV your work

(Hope to understand it eventually)

[lithoc]

Does anybody experiecing strange blocks in the video.
I'm experiencing some blocky B-frames with celtic_druid r146 build.

I usually encode with mencoder so I'm not sure if this is normal.



:confused:

[Sirber]

Something like this (http://forum.doom9.org/showthread.php?s=&threadid=90635)?

[Kurtnoise]

I've a question regarding the stats file (w/ r144 build). It looks like this :

in:5 out:6 type:B q:28.000 itex:127 ptex:379 mv:310 misc:288 imb:4 pmb:40 smb:640;
in:8 out:7 type:P q:26.000 itex:343 ptex:2908 mv:1356 misc:617 imb:17 pmb:184 smb:483;
in:7 out:8 type:B q:28.000 itex:163 ptex:531 mv:611 misc:479 imb:5 pmb:115 smb:564;
in:10 out:9 type:P q:26.000 itex:743 ptex:2616 mv:1272 misc:537 imb:24 pmb:131 smb:529;
in:9 out:10 type:B q:28.000 itex:309 ptex:944 mv:484 misc:407 imb:10 pmb:68 smb:606;
in:12 out:11 type:P q:26.000 itex:820 ptex:2487 mv:1283 misc:538 imb:25 pmb:132 smb:527;
in:11 out:12 type:B q:28.000 itex:510 ptex:752 mv:647 misc:451 imb:14 pmb:82 smb:588;
in:14 out:13 type:P q:26.000 itex:1186 ptex:2174 mv:1381 misc:619 imb:36 pmb:145 smb:503;
in:13 out:14 type:B q:28.000 itex:324 ptex:448 mv:629 misc:423 imb:10 pmb:84 smb:590;
in:16 out:15 type:P q:26.000 itex:426 ptex:2434 mv:1406 misc:526 imb:24 pmb:137 smb:523;
in:15 out:16 type:B q:28.000 itex:58 ptex:534 mv:328 misc:368 imb:4 pmb:58 smb:622;
in:18 out:17 type:P q:26.000 itex:535 ptex:1941 mv:1072 misc:476 imb:16 pmb:115 smb:553;
in:17 out:18 type:B q:28.000 itex:604 ptex:764 mv:599 misc:409 imb:16 pmb:70 smb:598;
in:20 out:19 type:P q:26.000 itex:923 ptex:2959 mv:1481 misc:565 imb:24 pmb:180 smb:480;
in:19 out:20 type:B q:28.000 itex:29 ptex:798 mv:565 misc:432 imb:2 pmb:103 smb:579;

What are exactly the itex, ptex and misc values ??

Thanks.

[Manao]

itex : texture size for intra macroblocks
ptex : texture size for inter macroblocks ( P + B )
mv : mv size for inter macroblocks ( P + B )
misc : header size for macroblocks
imb : intra macroblocks count
pmb : inter macroblocks count
smb : skip macroblocks count

texture size : size of the encoded DCT coefficients
mv size : size of the motion vectors, in bits ( not their actual length )
header size : macroblock size - texture size - mv size

[Kurtnoise]

10x Dude...;)

[Sharktooth]

I'm back on line... and my builds too.

[Tommy Carrot]

Sharktooth, the compiler bug is back in your latest build! This (http://www.fw.hu/carrotland/compilerbug.avi) is what i mean. If i remember correctly, the -O3 flag is the culprit.

[Sharktooth]

damnit, i reinstalled all the mingw stuff coz it was b0rked... now it's all ok but gcc has problems... argh... i hate it.
Anyone tested with 3.4.1.x? Does it show the same problem?

[len0x]

Originally posted by Tommy Carrot
Sharktooth, the compiler bug is back in your latest build! This (http://www.fw.hu/carrotland/compilerbug.avi) is what i mean. If i remember correctly, the -O3 flag is the culprit.

I've made a default complile of revision 149 with gcc 3.4.1.1 Can you check if the problem is still there? (core is still compiled with -O3). Get it here (http://len0x.leffe.dnsalias.com/x264vfw.zip)

[Sharktooth]

len0x can you try the -O3 switch in vfw too?

[len0x]

Here (http://len0x.leffe.dnsalias.com/x264vfw2.zip) is VFW compiled with -O3 (the rest is the same as my previous compile).

[Sharktooth]

OK, like i said in the other thread it's the -fomit-frame-pointer flag that should be avoided.
I dont know why but it is causing the effect you can see in the tommy carrot's sample.
Tested with gcc 3.4.2.

[hpn]

Seems lots of code has been added or changed in rev.150 dealing with b-frames, so I just tested the new Sharktooth's build with 3 b-frames (plus 8 ref. frames) and the encode looks smooth as silk without any artifacts, like blocking etc. I think 3 b-frames will be my way to encode from now on. However I noticed that there was no upper limit to the max b-frames number, so I tested with some insanely high numbers, like 50 or 100, just to see what would happen (I guess some code should be added to prevent people from doing this). The encoding starts but at about 60% of the first pass an "x264 error console" pops up, stating "specified frame type is not compatible with max b-frames" then VirtualDub keeps encoding and at the end of the first pass (99%) crashes and exits.

edit: also the x264-1.stats contains only I and P frames, so b-frames seems disabled in case of invalid max b-frames number

edit2: Couldn't find any "B-frame pyramid" option mentioned in the SVN to play with. Isn't it something that should be available in the user interface or it's only some "internal" encoder stuff?

[celtic_druid]

Max bframes is set to 16 in mencoder.

B-frame pyramid is enabled in the last mencoder build that I did. Use b_pyramid=1 to enable.

Also I did a rev151 build with it enabled in the VFW, don't think that has been mirrored though. Untill ffdshow gets updated you would need mplayer to play it anyway.

[hpn]

Originally posted by celtic_druid
Max bframes is set to 16 in mencoder.
Actually the max B-frames number that works in my VFW tests is 15. For 16 (or more) the encoding crashes during the first pass and the stat files contains only I and P frames.

By the way, is it a good idea to use 15 max b-frames for an average movie encode? For example Nero "Max definition - AVC" profile only allows 4 max b-frames and 3 for the other profiles. But when I examine a 15 b-frames x264 encode I can spot that some "complete dark" scenes really use 15 bframes, like pbbbbbbbbbbbbbbb-pbbbbbbbbbbbbbbb-pbbbbbbbbbbbbbbb..., which I guess delivers better compression than 3 bframes (pbbb-pbbb-pbbb..). Even if I set 15 b-frames 99% of the movie still uses no more than 4 consecutive bf, so seems it's pretty safe to put 15 and give the encoder the freedom to decide (especially if fenrir keeps tweaking the b-frames placement)

[akupenguin]

With CABAC, pure black frames will be compressed to nothing no matter whether they're P or B. Even if 15 B-frames doesn't crash, I wouldn't call it safe, as I've only just started testing more than 3. That said, one of the eventual goals of a B-frame placement algo is that increasing max B-frames should never hurt compression.

And it's sysKin and I that are tweaking B-frame placement. The last time fenrir touched x264 code was before B-frames were usable.

[hpn]

Originally posted by akupenguin
And it's sysKin and I that are tweaking B-frame placement.
My bad, sorry. Just a lapse of the tongue :D, cause I read some thread about fenrir a few hours ago. Keep up the good work.

[virus]

Originally posted by hpn
The encoding starts but at about 60% of the first pass an "x264 error console" pops up, stating "specified frame type is not compatible with max b-frames"
:)

Finally that code proves to be useful. Usually the error window surprises (scares?) the user, who doesn't expect such a feature. There's even a button that allows to copy the content of the window to the clipboard. All a n00b can ever need :D

[Sharktooth]

Originally posted by celtic_druid
Also I did a rev151 build with it enabled in the VFW, don't think that has been mirrored though. Untill ffdshow gets updated you would need mplayer to play it anyway.
Mirroring both 151 and 152 and avc2avi.

@akupenguin: Can you please add a checkbox for enabling/disabling B-Frames Pyramid in vfw too?

[MacAddict]

Amazing development speed! Just a big thanks to all those who are involved coding, testing, compiling, mirroring, etc.

[akupenguin]

Originally posted by Sharktooth
@akupenguin: Can you please add a checkbox for enabling/disabling B-Frames Pyramid in vfw too?
No, I don't do win32 guis. Bug virus or someone.

[Sharktooth]

Ok, celtic druid made a couple of patches for that, it also uncomments the Configure from the def's file and It also includes some crap that MSVC changed I think isn't really needed.

The diffs are here: http://www.aziendeassociate.it/cd/x264/pyramid.diff
and here: http://www.aziendeassociate.it/cd/x264/pyramid2.diff

Also there are some more parameters in CLI encoder that IMHO should be also added in the vfw interface:
--b-bias parameter (Influences how often B-frames are used)
--weightb (Weighted prediction for B-frames)
--sar (Specify Sample Aspect Ratio)

[bob0r]

[off topic but useful]
If any people want a *.x264.nl subdomain pointed to their static ip, just drop me a PM or an email sub@x264.nl.
Just for easy remembering and we can make a list of subdomains for x264 related info/downloads.
Could be handy for custom builds and other tests/experiments or what ever x264 related things you can think up!
[/off topic but useful]

I too must say x264 development is going great and i'll do my best to support x264 in the ways i can.

Carry on! :D

[unmei]

Can someone briefly explain what this B-frame pyramid is/does?
And what effect it could have when played in "non-ready" FFDShow?

I encoded a OVA using the non-patched rev 153 vfw today, but so far it seems to play without problems using the FFDShow from march 3..

[BoNz1]

Originally posted by unmei
Can someone briefly explain what this B-frame pyramid is/does?
And what effect it could have when played in "non-ready" FFDShow?

I encoded a OVA using the non-patched rev 153 vfw today, but so far it seems to play without problems using the FFDShow from march 3..

The bframe pyramid allows bframes to reference each other and because of this, some frame reordering must occur. If you encode with the bframe pyramid on, it will not play in the latest ffdshow. Likely it will stall after a couple frames. You will need to update libavcodec from ffmpeg and build a new ffdshow. The vanilla rev153 from the svn does not have bframe pyramids enabled by default so it will play correctly. BTW does anyone have a newer ffdshow than march 3?

[unmei]

OK, thanks a lot for the quick reply. So i better do not turn it on now :)

[celtic_druid]

Yes, don't turn it on if you want it to playback with current ffdshow. However ffdshow should support it in the future and mplayer supports it right now.

libavcodec hasn't been updated in the cvs so no real point in a new build. Also updating libavcodec in ffdshow is not that simple, the updates need to be modifed to work.

weightb currently gets enabled by default if bframes > 1.
b-bias I guess could be usefull, not so sure about sar.

[Tommy Carrot]

I'm curious, if a b-frame can be used as reference for other frames, the higher quantization of the reference b-frame wont hurt the overall quality? One of the advantage of the b-frame is that you can safely compress it more because it's not used as reference, hence it doesn't influence the quality of other frames. But this will change with pyramid b-frames. Could someone explain me how can x264 avoid this problem?