x264 development

[len0x]

Kudos to Syskin who made rev 128 compilable on MSVC! The only bit that I had to tamper with is manually define integer types because intypes.h is not present in MSVC. (VC version is definitely slower than gcc builds though)

[lithoc]

I am using x264 r128 + P4 2.8ghz(Northwood) + 1 GB RAM

I couldn't get x264 to work!!!

I've tried using it with avs2avi, it didn't work either.

Did I missed anything?

BTW, I've tried using mencoder. It works for me now but no B-Frames!!!

my cli is

mencoder - -nosound -noskip -o "new\temp.264" -ovc x264 -x264encopts keyint=500:frameref=15:deblockalpha=-3:deblockbeta=-5:ip_factor=1.4:pb_factor=1. 3:cabacidc=2:scenecut=40:cabac:8x8mv:4x4mv:b8x8mv:direct_pred=2:subq=5:qp_step=1:qp_min=10:qp_max=51:bframes=4:bitrate=2048 -ffourcc X264 -of rawvideo

CLI Log:
C:\Temp>x264 -o h1.h26l --rcbuf 64000 -B 128 --sar 4:3 --fps 23.97 --no-psnr c:\temp\t3video.avs 320x240
x264 [info]: using SAR=4/3
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2


C:\Temp>

[virus]

@lithoc

As for avs2avi, there's a new version which supports x264 (previous versions don't). As for the CLI encoder, it takes raw YUV as input, it cannot work with AVS files. As for mencoder, looks like you've ripped (an incomplete piece of) someone else's commandline without knowing what it does ;)

Have a look at my encoding pack (link in Sharktooth's sticky) if you want to use mencoder with some multipass scripts, or update avs2avi, or use VDub(mod).

hope this helps
virus :)

[Yong]

@virus:
I tried, it's work :)
but still can meet the target bitrate=800kbps,
with my poor "fast" first pass settings, the video bitrate is 359kbps,
after use the correct first pass, bitrate increase, 627kbps.
haven't try with nthpass encoding:p

@lithoc:
Don't try to copy my dangerous x264 CLI encoding options:p

[Sergejack]

Is the Jim Casaburi's temporal cleaner for VDUb somewhat useless with X264 ? As in the question "I'am a rigth thinking, there already is a natural similar effect due to bit not wasted on too low changes?"

I ask because I cannot manage to make that filter work on AVS (someone knows?).

[Sharktooth]

@Yong: try the new rev.130. It has significant changes to the rate control.

@Sergejack: Filtering "changes" the source in some way and it always matters for any codec.

[igor1st]

x264 VFW, default settings, max ref=15, no fast first pass, builds r130 by Sharktooth and r127 by celtic_druid.
VirtualDubMod closes silently on early stage of first pass (last frame in stats file is 4204). It's 100% repeatably.
Max ref=5 - no problem.
Now I run this encode with ref=5. Afterwards I will try to determine from which value of max. refs this problem occurs.

[Arkoki]

The last ARCalculator uses avs2avi to compress and it compress in x264 perfectly.
This version is in English too.
Here to download www.canalxvid.com

[dragongodz]

x264 VFW, default settings, max ref=15, no fast first pass, builds r130 by Sharktooth and r127 by celtic_druid.
VirtualDubMod closes silently on early stage of first pass (last frame in stats file is 4204). It's 100% repeatably.
Max ref=5 - no problem.
ok i dont know if this has anything t do with it or not, also i am going from memory since i had a look and cant find the particular post(theres a lot to go through :) ).
akupenguin mentioned and showed that the size of referenced frames can fill the buffer before that total reference total. that is you may have a reference of 15 frames but only be able to buffer 13 frames(from memory that was the amount he gave the example to). is the default 15 ? if yes then maybe setting the default to less may be a good idea.

i am sure he will correct what i just said and say i mixed it up or it is not relevant. ;)

[akupenguin]

the size of referenced frames can fill the buffer before that total reference total. That's a function of levels, which x264 ignores. It could conceivably cause a hardware player to fail, but won't affect encoding or software decoding.
And the default is now level 4.0, which allows a buffer size of 12MiB, which is 20 reference frames at 720x576.

[dragongodz]

It could conceivably cause a hardware player to fail, but won't affect encoding or software decoding.
i suspected as much but as i said i couldnt find where you talked about it before. these threads are so dman big now. thanks. :D

[Yong]

Originally posted by Sharktooth
@Yong: try the new rev.130. It has significant changes to the rate control.

@Sergejack: Filtering "changes" the source in some way and it always matters for any codec.

Yes, downloading now, try it later...:)

BTW i also have the same problem with igor1st, can i post the crashinfo.txt(generate by VirtualDub)here? i thinks it's helpful for x264 devs:)

[Sergejack]

Originally posted by Sharktooth
@Sergejack: Filtering "changes" the source in some way and it always matters for any codec.

It's about the Rate Distribution, if two consequential blocks are almost the same (like : PSNR Block1 - PSNR Block2 < Epsilon) does X264 still use some bits to show the unvisible changes (wich would most likelly introduce noise), or are those bits used on more bit needing blocks ?

Consider I use very low bitrate most of the time.

[akupenguin]

Yes, x264 skips blocks if the change is small. But if you don't sufficiently denoise the source, that noise might be enough to put some blocks over the threshold (even at very low bitrate).

[Sharktooth]

I always denoise (i use a combination of light filters so it wont hurt too much quality or details) so the encoder can work at it's best.
Most movies have added noise so... sometimes i just re-add that noise during playback with post-processing filters (ffdshow). It's just a matter of taste.

[igor1st]

Now I run this encode with ref=5. Afterwards I will try to determine from which value of max. refs this problem occurs.
I made some quick tests. Seems that with refs value below 15 this problem didn't occurs (at least on same position).

[Sergejack]

Originally posted by akupenguin
Yes, x264 skips blocks if the change is small. But if you don't sufficiently denoise the source, that noise might be enough to put some blocks over the threshold (even at very low bitrate).

Skips blocks ?... What about the motion data (vector) ?

[akupenguin]

H.264 predicts a motion vector for all blocks, based on the neighbors. A skipped block simply uses that predicted mv, with no further correction. A non-skipped block encodes the difference from the predicted mv, and then the texture residual.

[Sergejack]

Originally posted by akupenguin
H.264 predicts a motion vector for all blocks, based on the neighbors. A skipped block simply uses that predicted mv, with no further correction. A non-skipped block encodes the difference from the predicted mv, and then the texture residual.

As expected, but got to make sure of that ^^
Good, good. :D

[dragongodz]

skipped blocks go all the way back to mpeg1 so its not something new to be worried about. :)

[Sergejack]

Originally posted by dragongodz
skipped blocks go all the way back to mpeg1 so its not something new to be worried about. :)

It didn't sound so needed by the VP6 devs then.

[bob0r]

Package mingw32 installed.
Package subversion installed.
Package nasm installed. (http://nasm.sourceforge.net/wakka.php?wakka=HomePage nasm-0.98.38)


How do i compile x264vfw.dll with debian?

svn co svn://svn.videolan.org/x264/trunk x264
cd x264

... and then?

Edit:
Never mind i guess, i can compile it in windows now :D

[hpn]

Just finished a full movie speed test, 153'032 frames, frame size 688x288,~700kbps, insane codec settings:

x264 - revision 136 (slow first pass, mRF 15, mBF 1 temporal, all partitions enabled, pdq 5)

total time: 8:35.44h
1st pass: 3:56.43h
2nd pass: 4:39.01h

------------------------------
Nero Recode version 2.2.6.11 (Maximum definition - AVC, mVR -512 + 511.75, mRF 8, mGS 300, mBF 3, DS 2, audio&subs disabled)

total time: 11:36.41h
1st pass: 2:06.45h
2nd pass: 9:29.56h

(AMD XP 2600+ Barton, 768MB DDR, Windows XP SP2)

[lithoc]

Just curious about the quality of both encode?

Since x264 is open source and Nero is not.

What are the chances that x264 will be the "next" encoder of choice in term of quality & speed?

[Doom9]

What are the chances that x264 will be the "next" encoder of choice in term of quality & speed?Only the future will tell ;)

And you know, quality is in the eye of the beholder, so it's best you do your own tests and see with your own eyes.

By the way, now that we have adaptive B-frames (it's amazing how fast things progress, makes one wonder how x264 will do in the next codec comparison), is ffdshow up to the task (meaning does it have proper bvop deblocking now)?

[hpn]

Originally posted by lithoc
Just curious about the quality of both encode?
Since x264 is open source and Nero is not.


I didn't want to post screenshots, cause seems x264 have some problem with noisy sources, like the one I used, preserving less details that Nero, so I wanted to investigate what could be wrong. Maybe I'll try the same x264 encode without the denoising filter in the avs (GKnot uses it by default). Actually during playback some may think that x264 looks "better than the original", because of the smoother picture, but of course this is very deceitful. Another thing is that DGIndex reports "interlaced" frame type, but the movie looks absolutely progresive to me (any ideas?). Maybe both fields are identical or something. Afaik x264 does not support interlacing, so I don't know if this could cause a problem in this particular case. And finally, it's a complete nightmare taking screenshots from a Nero encode with MPClassic (no such problem with x264 or the source). Due to some unknown reason MPC sometimes captures the preceding frame, not the one I want, so I had to discard a few chosen frames in order to produce identical screenshots.

Anyway, here are some shots:

http://www.freewebs.com/hdar/2/index.html
http://www.freewebs.com/hdar/2/index2.html
http://www.freewebs.com/hdar/2/index3.html
http://www.freewebs.com/hdar/2/index4.html
http://www.freewebs.com/hdar/2/index5.html

[Doom9]

And finally, it's a complete nightmare taking screenshots from a Nero encode with MPClassic (no such problem with x264 or the source). Due to some unknown reason MPC sometimes captures the preceding frame, not the one I want, so I had to discard a few chosen frames in order to produce identical screenshots.Welcome to my world.. now imagine this times 10 and you have the most annoying part of a codec comparison..

[dbzgundam]

Hmm, I see Generic, Athlon XP, and P4 builds available. I'm not sure about either, so would (in theory) the P4 build assist a 64-bit Athlon more, due to the SSE2 being present in the Athlon64 and P4? (Unless the Athlon XP build helps in a different way...)

[fRUTTiFrESH]

Done some quick benchmark (with the default settings) this morning with rev142:

AthlonXP 3000+ (Barton Core), 512MB (DDR-RAM), XPsp2, 7200RPM sATA HDD


Test-Movie:

Calculator:
VideoSize: 45532 kbyte.
Audio1Size: 19578 kbyte.
Audio2Size: 0 kbyte.
Overhead: 424 kbyte.
AviSize: 65536 kbyte (64 mbyte).
FilesSize: 0 kbyte.
TotalSize: 65536 kbyte (64 mbyte).
Interleaving: ac3
Bitrate: 1041 k(=1000)Bits/s
Frames: 8951
FPS: 25.000
Duration: 05:58
Quality: 0.254 bits/(pixel*frame).
CompCheck3: 0.000 bits/(pixel*frame).
CompCheck5: 0.000 bits/(pixel*frame).
Resolution: 640 x 256


X264VFW_rev142.exe:

1pass: 16.916 Frames per Second.
2pass: 16.064 Frames per Second.

Total Encoding Time: 18 minutes, 15 seconds.


X264VFW_rev142_athlonxp.exe:

1pass: 17.945 Frames per Second.
2pass: 16.941 Frames per Second


Total Encoding Time: 17 minutes, 15 seconds.


Encoded output looks great!

[Doom9]

@dbzgundam: if the P4 build uses a single line of SSE3 you're SOL with every existing Athlon64. Just something to keep in mind. P3 only has SSE1 and SSE2.

[ViCroié]

I made some of my 1st X264 full movie encodes.
I'll post the details and some screens later

I encoded a 1 1/2 hour movie (lot of dark scenes, low motion) in:
XviD1.1.0 BETA (H263 quant, VHQ=2, all options on)
XviD1.1.0 BETA (HVS-better quant, VHQ=2, VHQ for Bframes, rest default)
X263 rev.136 (defaults + 15 ref frames, 1 Bframe)

Another 1 1/2 hour movie (lot of contrast, high motion) in:
XviD1.1.0 BETA (H263 quant, VHQ=2, all options on)
XviD1.1.0 BETA (HVS-better quant, VHQ=2, VHQ for Bframes, rest default)
X263 rev.142 (defaults + 5 ref frames, 1 Bframe)

(both movies were encoded 2-pass to match 1CD size)

I just looked at the result of the 1st movie, and it looked great.
Biggest difference i could see with the XviD encodes was that it looked much more clean, when i watched in window XviD(HVS) looked great to me... but whenever i watch it fullscreen i could see much more ringing and blocking then when i watched the X264 encode, the dark scenes also looked better with X264.

Also it looked like X264 (or AVC in general) has no real troubles with anything, i tried encoding dark/bright scenes, mist, smoke, cartoon, CG, water, fire but it all looked good. Also i tried some heavy sharpening before encoding like, unfilter(10, 10) and lanczos4Resize after. Encoding this wasn't very rewarding with XviD because it just made more noise and blocks appear, but with X264 it was definitely looking better then the non-sharpened version without getting extreme ringing/blocking.


I don't understand how X264 is developed so fast, but its great :D
THX

[Sharktooth]

Originally posted by Doom9
@dbzgundam: if the P4 build uses a single line of SSE3 you're SOL with every existing Athlon64. Just something to keep in mind. P3 only has SSE1 and SSE2.
It does no use sse3 since not all P4s have sse3. But still wont run correctly on A64s.
Athlon XP build should work better and faster on A64s.

EDIT: I added an Athlon-64 32bit compile. Test if it's faster than athlon xp build on athlon 64 cpus.

[Doom9]

am I correct in assuming that weighted prediction for b-frames and adaptive b-frames are turned on in the VfW builds? And if so, are those options dependant on any others (for instance, number of b-frames configured)?

[bond]

Originally posted by Doom9
am I correct in assuming that weighted prediction for b-frames and adaptive b-frames are turned on in the VfW builds?yep

And if so, are those options dependant on any others (for instance, number of b-frames configured)?weighted pred will only work with more than 1 b-frames (mainly because it doesnt make sense technically using it on 1 b)

adaptive should be independant of the b-frame number

[len0x]

VFW in VDubMod crashes half way through the first pass. Always the same place (after frame 1639 of that Spiderman trailer vob that was used for quality test vs Nero). Settings: all defaults plus 5 reference frames. Did not happen with revision 142.

*Edit* tried rev 143 and its fine. So its definitely changes in 144...

[azsd]

rev 144,Encoded frame were Shifted....
Max reference frames:2
Max B-frames:3
other settings using default.
their have 0,1,2 frame are null in vdm,orginal #0 frame became #3,every orginal frame became +3 at encoded video,and lost last 3frames.
same video encoded with rev136,
Max reference frames:0
Max B-frames:0
frames has exactly matched of the orginal source avs script.

ffdshow 20050224 snap
x264 rev.144 p4 build

[bond]

Originally posted by azsd
Max B-frames:3
other settings using default.
their have 0,1,2 frame are null in vdm,orginal #0 frame became #3,every orginal frame became +3 at encoded video,and lost last 3frames.known problem, caused by the outdated vfw codec interface used virtualdub(mod), use mencoder to solve this

[virus]

Originally posted by bond
use mencoder to solve this
...or load the clip in vdub(mod) and trim away the zero-length frames at the start. vdub(mod) shows them with a D (dropped) in the status bar. BTW this procedure of trimming manually the dummy frames at the start of x264 encodes with bvops seems to be necessary, at least on my machine, to be able to open the clip using AVISource() or AVIFileSource(). DirectShowSource() instead opens the clips no matter if they're trimmed or not, but they're shown upside-down... don't know what's wrong here. :confused:

[bond]

Originally posted by virus
...or load the clip in vdub(mod) and trim away the zero-length frames at the start.this will still lead to that the .avi will have less frames than the source

[azsd]

thx,I guess the max bframe number = droped value

:confused:
does the mencoder called the x264 thought vfw or using x264 build in old ffmpeg?
or is there other tools can do avc encoder using vfw x264 codec just like VirtualDub (and unlike in known problem)?
commandline version x264 always hard to set the arg and can't set it prority,I can't browse webpages smoothly when it eating my cpu load.

[Doom9]

does the mencoder called the x264 thought vfw or using x264 build in old ffmpeg?Neither.. it uses the same library as the VfW interface. You can have both ffdshow and mencoder with x264 or without, and you can compile old libraries into an up-to-date ffdshow and the other way round ;)

Celtic druid's 2/25 mencoder compilation includes revision 144 of the x264 library, just like the VfW interface from the top of this forum.

You can use a GUI like MeGUI (http://forum.doom9.org/showthread.php?s=&threadid=87567&goto=lastpost) to encode with it.. no messing with the commandline, it offers access to more x264 options than the VfW, it allows you to set the priority, and there's a lot more (for instance MP4 output where you don't have those problems that VfW causes (though to be perfectly honest, I never felt this was a big issue))

And btw, the frame delay happens to all VfW codecs that use b-frames.

[bond]

Originally posted by azsd
thx,I guess the max bframe number = droped value indeed

does the mencoder called the x264 thought vfw it uses its own interface (not vfw)

[DeathTheSheep]

I use AVIMuxGUI to get avc and aac-he into my AVIs. However, all ffdshow versions after early Feb. don't support aac in avi. What is going on?

[azsd]

I think it means the avc witch can mux in avi that had limited and tranforming for fit avi frame model,
not every H.264 encoder generate the warped avc for avi muxing.

so you can mux them in mkv and use haali's splitter,then it can decode by ffdshow correctly,
or use x264 for avc in avi.

[virus]

Just a couple of things: I've found a little b0rk in VfW. In revision 117 akupenguin did a little mistake while cleaning up the fast1pass code. That resulted in a 1stpass a bit slower than needed in most cases. Here's a patch (http://www.webalice.it/riccardo.stievano/video_stuff/vfw-fast1pass-b0rk.diff) that restores 1st pass speeds as they were before revision 117.

Another thing: the web interface for the development maillist (http://www.via.ecp.fr/via/ml/x264-devel/) has been finally fixed, for those of you interested in taking a look. Also the problem with the SVN repository has been resolved (checking out x264 code was not possible during this weekend). Big thanks to fenrir who talked to all the right people in order to get things fixed :)

virus

[DigitalDeviant]

Originally posted by Doom9 Celtic druid's 2/25 mencoder compilation includes revision 144 of the x264 library, just like the VfW interface from the top of this forum.

Can anyone point me to where I can download any of his mencoder bulids past 2/22?

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

[DigitalDeviant]

I tried that build but it keeped telling me I needed avs2avi.exe in the same directory, even after I put a copy of it in. Plus I can't tell if that build is using the latest x264 revision.

[lithoc]

Originally posted by DigitalDeviant
I tried that build but it keeped telling me I needed avs2avi.exe in the same directory, even after I put a copy of it in. Plus I can't tell if that build is using the latest x264 revision.

Do you have the full command line??

I assume you are using the old MeGUI which use avs2avi.
Try update to latest MeGUI will solve your problem.

http://forum.doom9.org/showthread.php?s=&postid=617805#post617805

This is because mencoder support avs natively now.


;)

[celtic_druid]

I would suggest a newer version anyway.
http://www1.mplayerhq.hu/cgi-bin/cvsweb.cgi/main/libmpcodecs/ve_x264.c?cvsroot=MPlayer&sortby=date
I did fresh compiles about 5 hours ago. Hopefully they will get mirrored soon.

Although x264 is now upto r146 (as of 20mins ago or so).
edit: did new compiles with x264 r146.

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

[Manao]

By making the quantizer of bref lower than non-references bframes.

Moreover, bframes aren't only efficient because they allow to raise the quantizer : a clip with b & p at same quantizers will have a higher PSNR than a clip without bframes.

That allows bref, even if they are less quantized than 'normal' bframes, to raise yet again the quality.

[Tommy Carrot]

Thanks, that's what i thought too. :)

[sysKin]

Originally posted by 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? Because AVC allows multiple references in every direction, any block has a choice, whether to motion compensate from closer (but possibly lower quality) picture, or from further away, but lower quant, pframe. So it's simply about extra choice :)

Radek

[Koti]

If you encode with the bframe pyramid on, it will not play in the latest ffdshow. Likely it will stall after a couple frames.

Hehe, Yep ffdshow stall - crash , but nero's avc decoder works with b frame pyramid.

[TheUnforgiven]

Great work
but could somebody add a status window or at least a simple debug output to the vfw version.
i hate to encode blindly!

[celtic_druid]

Someone want to test this? http://celticdruid.no-ip.com/test/libavcodec.bpyramid.7z

patched libavcodec for ffdshow. Works ok decoding bframe pyramid encodes here. Although I didn't test much.

[Yong]

Here's the info from mailing list:
r152 | pengvado | 2005-03-05 05:16:05 +0100 (Sat, 05 Mar 2005) | 2
lines
Changed paths:
M /trunk/common/common.h
M /trunk/encoder/encoder.c
M /trunk/encoder/ratecontrol.c
M /trunk/vfw/config.c

allow 16 refs (instead of 15)

--
This is the x264-devel mailing-list
I tried with mencoder with frameref=16, but mencoder still complaining frameref>16 and stop the encoding job...:(
EDIT: i use x264r153 and mplayer daily CVS build.

[Teegedeck]

Originally posted by celtic_druid
Someone want to test this? http://celticdruid.no-ip.com/test/libavcodec.bpyramid.7z

patched libavcodec for ffdshow. Works ok decoding bframe pyramid encodes here. Although I didn't test much.
It works flawlessly, even on a clip with max. 10 ref. frames and max-idr=500. Thanks a lot!

[akupenguin]

Originally posted by Yong
I tried with mencoder with frameref=16, but mencoder still complaining frameref>16 and stop the encoding job... I haven't patched mencoder to loosen that restriction, since 15 B-frames is overkill too. This is just to prevent a crash found by Spyder, who is writing his own frontend.

[Yong]

Originally posted by akupenguin
I haven't patched mencoder to loosen that restriction, since 15 B-frames is overkill too. This is just to prevent a crash found by Spyder, who is writing his own frontend.
I haven't test with b-frames=16,
but what i say is frameref=16:)

[Sharktooth]

Can someone please test my latest build (rev156) with the celtic druid's patch?

[mezzanine]

Originally posted by Sharktooth
Can someone please test my latest build (rev156) with the celtic druid's patch?

Just did, works fine.

[Sharktooth]

good ;)

[scorpdt]

Works fine on my end too.

[celtic_druid]

If you want 16 ref frames then you need to change ve_x264.c max ref value from 15 to 16 which I did in my last mencoder compile anyway.

About the VfW GUI. I shifted some stuff round. Anyone got any comments/advice on that? Just thought that with the two new bframes settings added it should have its own section.

[Chainmax]

I have a couple of questions that are probably extremely n00bish, so please bear with me. From what I read all this time, AVC used to have blocking issues on bframes and that was due to lack of deblicking on the decoding end. Will postprocessing be always necessary? I never play my Xvid encodes with postprocessing, and I'd like to do the same with future AVC encodes, will that be possible? Also, is there any chance that x264 can output .mp4 files since AVC in AVI is such a bad idea according to the FAQ?

[Doom9]

Also, is there any chance that x264 can output .mp4 files since AVC in AVI is such a bad idea according to the FAQ?Please have a look at the x264 sticky: http://forum.doom9.org/showthread.php?s=&threadid=89979

There you can find a quote from yours truly that applies here: x264 is encoding application agnostic. The output format is encoding application dependant, not codec dependant. VDub and every other VfW based tool will give you video in the AVI container. mencoder, can also give it to your RAW. ffmpeg can output to MP4, but that feature is kinda broken, and currently x264 is not integrated into ffmpeg. So, there is no application that can encode using the x264 codec and put the video data into the MP4 container. You'll need to either create a raw output and mux that into MP4 using a tool like mp4creator, or make an AVI, extract the AVC video using avi2raw, then mux the raw data into MP4. The first approach is used by MeGUI (http://forum.doom9.org/showthread.php?s=&threadid=87567), the 2nd by AutoAC (http://forum.doom9.org/showthread.php?s=&threadid=90732) and mp4muxer (http://forum.doom9.org/showthread.php?s=&threadid=89803). Now the choice is yours.

Note that even though mp4creator supports AVI input, it cannot handle the tricks used to get B-frames into AVI, so don't use mp4creator with AVI input.. always go via RAW. The tools mentioned above will do that automatically for you.

[Tommy Carrot]

Originally posted by Chainmax
I have a couple of questions that are probably extremely n00bish, so please bear with me. From what I read all this time, AVC used to have blocking issues on bframes and that was due to lack of deblicking on the decoding end. Will postprocessing be always necessary? I never play my Xvid encodes with postprocessing, and I'd like to do the same with future AVC encodes, will that be possible? Unfortunately the blocking in h.264 is much more visible and annoying than in ASP, so deblocking is necessary. The best you can do is to weaken the deblocking as far as you can while the image is still relatively clean, but completely disabling the loop-filter is not a good idea imo. Akupenguin hinted though that high profile may bring an improvement in this field.

[Doom9]

Unfortunately the blocking in h.264 is much more visible and annoying than in ASP, so deblocking is necessary. The best you can do is to weaken the deblocking as far as you can while the image is still relatively clean, but completely disabling the loop-filter is not a good idea imo. Should that even be possible? I thought the in-loop filter was a given for AVC. And to the best of my knowledge, neither Nero AVC nor VSSH actually has postprocessing in their decoder (I know for sure for Nero), but I figure the in-loop filter is still active because they don't have any issues with B-frames, even in the absence of dedicated postprocessing in the sense we know it from MPEG-4 ASP codecs.

And, I only have limited experience with x264 in that area, but when I disabled postprocessing in ffdshow, the movie I watched looked much more visually pleasing.. postprocessing introduced a lot of visible artifacts. So I guess I should watch that same movie using the Nero filters to check for a difference.. and it would probably also be interesting to see how the Nero filters do playing contents where ffdshow has/had those blocking issues.

[netchris]

Nero decoder should be more complete compatibility wise, though i dont have any problems decoding my nero-avc encodes with ffdshow.
Its true that even minimal ffdshow postprocessing only harms the picture. Besides postprocessing aint needed in avc (thanks to inloop magic).

[akupenguin]

Originally posted by Chainmax
From what I read all this time, AVC used to have blocking issues on bframes and that was due to lack of deblicking on the decoding end. Will postprocessing be always necessary?
The deblocking that was lacking in ffdshow was in-loop filtering, not postprocessing. It is not a decoder choice; any decoder that doesn't perform deblocking (when specified by the encoder) is not standards compliant.

At this time, there are no known postprocessors for H.264, and using a postprocessor designed for ASP will only reduce the video quality.

[hpn]

Just tested the ST's rev.157. The so called "B pyramid" is now officially available in the VFW under the "Use as a reference" option (correct me if I'm wrong). Max b-frames is limited to 5, hopefully temporarily until the bframes code gets tweaked in the future (more b-frames always sounds tempting). For now to enable "Use as a reference" is a bad idea cause ffdshow is still unable to play such encodes (hopefully also fixed soon). MPlayer playes such encodes fine, as long as you use less than 15 ref. frames. For 15 and 16 refs and "Use as a reference" option enabled, Mplayer crashes stating: "MPlayer interrupted by signal 11 in module: decode_video, - MPlayer crashed by bad usage of CPU/FPU/RAM." I have no idea if it's a bug in the encoder or Mplayer (same bug with the patched 156 yesterday). And finally I still wonder what was the reason for upping the Max ref. frames from 15 to only 16 (why not to 24 for example). Either 15 or 16 is overkill anyway, so I don't get it. I guess theoretically we don't have an upper limit for ref. frames, as long as the encoding time remains reasonably low and real time playback of the resulting encode can be achieved.

[akupenguin]

16 is the max allowed by the H.264 standard. It was previously limited to 15 because 16 crashed the encoder.

[hpn]

That explains everything, thank you, akupenguin. Just keep up the nice work.
(I wouldn't be surprised if the "Moving Picture Experts Group" guys are already secretely working on some next gen. standard)

[Doom9]

The deblocking that was lacking in ffdshow was in-loop filtering, not postprocessing. It is not a decoder choice; any decoder that doesn't perform deblocking (when specified by the encoder) is not standards compliant.Thanks for the confirmation. So, until recently ffdshow's AVC decoder was not specs compliant and hence the b-frame quality problems.

and using a postprocessor designed for ASP will only reduce the video quality.I can absolutely confirm that, so make sure you disabled postprocessing in ffdshow when watching x264, or other AVC content. I guess it would be nice if that were done automatically considering that having it turned on only harms the output.

[JimiK]

First, also from me a big thanks to all people involved in this project!
Should referring frames look better when B-Frames are also used as reference?
It does not seem to decrease filesize. At least in my (short) test the size increased always by a very slight amount when B-Frames were used as reference.
In the mplayer manpages also stood that it would introduce an additional delay of 2 frames (maybe of #max_bframes frames?). I couldn't check this with mp4, because VDubMod as my editing program can only open avi. With Avi there are #max_bframes as dummy frames insertet, no matter if B-Frames are used as reference or not.

[stephanV]

AFAIK b-refs should not necessarily introduce an additional delay when b-frames were already used.

How useful b-refs will be still has to be seen. For anime it seems to work, for real content it is not sure.

[Sagittaire]

VFWx264 rev 157 (celtic_druid)

With ffdshow or ateme dec
defaut + 16 refs: bug for player (MPC)
defaut + 15 refs: no bug
defaut + bframe ref: bug for player (MPC)

with Nero AVC dec:
defaut + 16 refs + bframe ref: no bug but very high CPU level for player (MPC)

[Sharktooth]

@sagittaire: What decoder you use?

[Sagittaire]

VFWx264 rev 157 (celtic_druid)

With ffdshow or ateme dec
defaut + 16 refs: bug for player (MPC)
defaut + 15 refs: no bug
defaut + bframe ref: bug for player (MPC)

with Nero AVC dec:
defaut + 16 refs + bframe ref: no bug but very high CPU level for player (MPC). Video fluidity is worst.

[bond]

Originally posted by stephanV
[B]AFAIK b-refs should not necessarily introduce an additional delay when b-frames were already usedi dunno in what way b-frames as references makes arbitrary frame orders necessary, but with .avi you get one additional delay caused by the reordering (as done by x264 atm), which .avi isnt really capable to handle

of course with better containers, like .mkv and .mp4, which are able to handle arbitrary frame orders explicitely, this shouldnt happen

[Tommy Carrot]

But even with avi, it shouldn't introduce more delay. If the delay is equal to the maximum consecutive b-frame number, all of them are already buffered, so the order of them shouldn't matter.

[bond]

(23:35:02) (@pengvado) bond: avi doesn't support arbitrary frame orders any more or less than it has always supported unpacked B-frames.
(23:35:34) (bond) yep, but in practice it seems to work!?
(23:35:40) (@pengvado) the only thing wrong with AVC-in-AVI is timestamps / A-V sync.
(23:35:59) (@pengvado) the codec has sufficient info to reorder the frames for output
(23:36:32) (bond) hm can you explain how this works now using arbitrary orders with x264 in .avi?
(23:36:34) (@pengvado) however, since the only things that AVI does are seking and A-V sync, losing half of that does make it "broken" for all I care
(23:38:09) (@pengvado) x264 creates an elementary stream and hands it to mencoder. mencoder adds AVI headers and writes it to a file. mplayer reads the file, throws away the AVI headers, and gives the elementary stream to libavcodec. libavcodec reorders frames based on H.264 headers, and outputs in the correct order with undefined timestamps.
(23:38:45) (bond) hm and how would the reordering work out in practice, eg if decoding in vfw
(23:39:00) (bond) i mean with that 1 frame in/1 frame out limit
(23:39:23) (@pengvado) the first frame is output 3 times, the last 2 frames are dropped, and you get a 80ms A-V desync.
(23:39:38) (bond) ah so simply a bigger delay?
(23:39:58) (@pengvado) yes

[Tommy Carrot]

Akupenguin obviously knows a lot more about this stuff than me, but i still don't get it why should a bigger delay be necessary?

The delay is caused by a buffer to reorder the frames, because a reference frame must be placed before the frames which are using it as reference. let's see an example with 3 bframes:I b b b P
1 2 3 4 5 ; frames in original order
You have to reorder it to:I P b b b
1 5 2 3 4 ; after the reorderingYou need to buffer 3 frames, because the P-frame moves 3 frames away from its original place.

With bref this will be:I b B b P ; B is the b-frame which is used as reference
1 2 3 4 5This is stored like this:I P B b b
1 5 3 2 4As you see, you still only need to buffer 3 frames, i don't see the reason of the additional delay.

[Sagittaire]

hmm ... x264 in mp4 or mkv container don't work very well with multiref + bref ...

Perhabs muxing process:
avi2raw.exe -v x264-447.avi clip.h264
mp4creator.exe -c clip.h264 -rate 25 clip.mp4

if I use remux ateme exe result is the same: video playback is not very good with multiref + bref

[bond]

Originally posted by Sagittaire
hmm ... x264 in mp4 or mkv container don't work very well with multiref + bref ...i get this too when using bref (not with mref alone). i think thats caused by ffdshow. try the nero decoder, wait for ffdshow to be officially updated by milan to the latest ffmpeg sources or use latest mplayer

[stephanV]

Tommy Carrot: thats what i thought too :)

for 2 cons b-frames with b-ref it might be necessary though... IIRC the frame sequence will always be like this then:

1 2 3 4
I b B P

1 4 3 2
I P B b

thus three frames delay needed...

[Sharktooth]

I had some spare time this evening so i added some CPU optimized builds back to the x264 daily builds thread.
If you have some request for a particular version (SSE3?) just ask, i have still a couple of free hours.

[Sagittaire]

x264 and variability:


|---------------|---------|---------|
| Variability | OPSNR | SSIM |
|---------------|---------|---------|
| 000% | 39.3871 | 64.05 |
| 010% | 39.6695 | 65.23 |
| 020% | 39.9377 | 66.31 |
| 030% | 40.1266 | 67.08 |
| 040% | 40.2793 | 67.70 |
| 050% | 40.3925 | 68.19 |
| 060% | 40.4644 | 68.50 |
| 070% | 40.5003 | 68.66 |
| 080% | 40.4851 | 68.63 |
| 090% | 40.4357 | 68.51 |
| 100% | 40.3381 | 68.13 |
|---------------|---------|---------|


Optimal setting for this source and this quant is 75%. Optimal variability is perhabs not constant (change perhabs with source and average quant level) ...

[Sharktooth]

Uhm, what source?

[virus]

Originally posted by Sagittaire
x264 and variability
This is quite consistent with my own tests. If you want to optimize for Average PSNR, something around 40-50% should be good. If instead you want to optimize for Overall PSNR, you need to have a more "constant quantizer" behaviour, and so high values of variability are needed (70-90%).

The actual default (60%) should instead be a good starting point to find the maximum visual quality... but since visual quality is totally subjective (and things change when you change source and/or bitrate), that 60% is really just an hint. If some consensus can be reached on a different default which "looks better" on a wide range of sources we may ask akupenguin to change it. Rememeber that akupenguin tests on anime, so I'd suggest to investigate natural material... ;)

virus

[Tommy Carrot]

Originally posted by stephanV
Tommy Carrot: thats what i thought too :)

for 2 cons b-frames with b-ref it might be necessary though... IIRC the frame sequence will always be like this then:

1 2 3 4
I b B P

1 4 3 2
I P B b

thus three frames delay needed... Why? No matter how i see this, 2 frames delay should be enough in this case. And i know this doesn't matter here, as this is a purely theoretical discussion but doesn't x264 only uses b-ref with 3 or more consecutive b-frames?

Anyway, the question is still: why should b-ref introduce more delay?

[DeathTheSheep]

16 is the max allowed by the H.264 standard. It was previously limited to 15 because 16 crashed the encoder.

Really?!! I used more than 30 reference frames with revision 144 (or 139, I forgot) and it worked perfectly. There was a small file decrease over using 15.

I never experianced a crash until I tried to use 1000 (just for a test), and only then after the encode was nearly half finished. I think its limited to the amont of ram available, but by god i'm not sure and I know nothing.

Strange, though, how it actually did work for me. And yes, pyramiding does crash ffdshow.

Sheers. I mean, Cheers, y'all. Baa

[Sirber]

16 has always been working for me :confused:

[Manao]

Really?!! I used more than 30 reference frames with revision 144 (or 139, I forgot) and it worked perfectly. There was a small file decrease over using 15.Lol, amazing considering that the norm doesn't allow more than 16 references, and that x264 didn't allow more than 15 references before rev 152.

Moreover, and for the nth time, you won't notice any improvements with more than 5 references, and in fact, more than 2 references is often plainly useless considering the slowdown it creates.

[akupenguin]

Originally posted by Sirber
16 has always been working for me :confused: As with many of the options, if you select an invalid value, x264 clips it into the valid range. So your encode actually only used 15 refs.

Anyway, I increased the max not because 16 makes any difference, but because the limatation to 15 was caused by a bug.

[DeathTheSheep]

I've just looked back on an older version of x264 Revision 94. It seems to have a better compression ratio than the current one, and its .dll is much larger. Why is this? Seriously, with q=26 and similar options in both, the older version compressed better. Is this just because I'm doing something wrong (as usual?)?
Also wierd.



Yeah, and that reference thing... makes sense now that you mention the automatic value truncation, but that didn't work in older ones, I don't think, because there actually was a crash with 1000 and the filesize was a bit less than when I had used 15. Very, very strange. Want a file sample? (If i had somewhere to upload)

And Moreover, and for the nth time, you won't notice any improvements with more than 5 references, and in fact, more than 2 references is often plainly useless considering the slowdown it creates.

Yes, I totally agree. I was just doing it for testing purposes. ;-)

[Sagittaire]

Originally posted by virus
This is quite consistent with my own tests. If you want to optimize for Average PSNR, something around 40-50% should be good. If instead you want to optimize for Overall PSNR, you need to have a more "constant quantizer" behaviour, and so high values of variability are needed (70-90%).

The actual default (60%) should instead be a good starting point to find the maximum visual quality... but since visual quality is totally subjective (and things change when you change source and/or bitrate), that 60% is really just an hint. If some consensus can be reached on a different default which "looks better" on a wide range of sources we may ask akupenguin to change it. Rememeber that akupenguin tests on anime, so I'd suggest to investigate natural material... ;)

virus

best visual quality is subjective but for [60%-90%] interval variability metric is in practice constant : 60% for default setting is a good value for metric too ...

@DeathTheSheep
q24 for previous version is not equivalent at q24 for current version. Probaly RD setting, bframe ratio, bframe sensivity or other ...

q2 size for DivX and q2 size for XviD are very different with exactly the same setting but DivX and XviD obtain near result with same bitrate and with very different average quant ...

[DeathTheSheep]

True. I see. So does the compression quality subtly increase after each revision? Or are the absolute only changes limited strictly to what is written in the log?

[akupenguin]

Encoding delay is equal to the max consecutive B-frames. Decoding delay is 1 when traditional B-frames are used, and 2 when B-pyramid is used.

Note that only 1 delay is needed in order to ensure that each decoded frame is available in time for output:I b b b P
1 2 3 4 5 ; input order

I P b b b
1 5 2 3 4 ; coded order
- 1 2 3 4 5 ; display order

With B-pyramid, you need 2 delay to make sure frame#2 is decoded in time:I b B b P
1 2 3 4 5 ; input order

I P B b b ; coded order
1 5 3 2 4
- - 1 2 3 4 5 ; display order

Either way, decoding delay is independent of max B-frames:I b b b B b b b P
1 2 3 4 5 6 7 8 9 ; input order

I P B b b b b b b ; coded order
1 9 5 2 3 4 6 7 8
- - 1 2 3 4 5 6 7 8 9 ; display order

But note that the current B-pyramid is not the only way to use B-refs. Not all strategies require extra reordering, and some require more than 2 decoding delay and/or extra encoding delay. The following (not used by x264) requires 3 delay:I b B b B b B b P
1 2 3 4 5 6 7 8 9 ; input order

I P B B b b B b b ; coded order
1 9 5 3 2 4 7 6 8
- - - 1 2 3 4 5 6 7 8 9 ; display order

Of course, when I speak of delay, it only means delay between when you give a coded frame to the codec and when it returns the result. If the demuxer provides correct timestamps, the player can always decode enough frames in advance that the user won't see any delay.

[Tommy Carrot]

Thanks for the clarification, i was thinking only about the encoding delay. :)

[Capirossi]

nice codec :cool:

[lithoc]

Since rev150, I can't playback anymore.
It only playback for less tha a second then it crashed.

mplayer says:
[h264 @ 008E8E08]reference picture missing during reorder

Disregard if this issues have been identified.

Thanks for the great codec, now just hope it's compatible with hd-dvd/avc hardware player when it release

:)

[Sharktooth]

Try updating mplayer...

[lithoc]

Originally posted by Sharktooth
Try updating mplayer...

I'm using mplayer dated 5th March from http://oss.netfarm.it/mplayer-win32.php

Problem still exist

[Chainmax]

Originally posted by Doom9
there is no application that can encode using the x264 codec and put the video data into the MP4 container. You'll need to either create a raw output and mux that into MP4 using a tool like mp4creator, or make an AVI, extract the AVC video using avi2raw, then mux the raw data into MP4.

I understand, but the FAQ says that AVC in AVI doesn't allow implementation of some AVC features. What I don't fully understand is wether these limitations can appear at the encoding level (thus creating "broken" encodes) or just at the decoding level (so just using your suggestions would solve the problem.


I also have another question: I see that the H.264 specs include RDO and my question is wether H.264's RDO is identical to Xvid's VHQ or if there can be different approaches to RDO. Also, can Trellis be implemented in x264 or am I just talking nonsense?

[akupenguin]

Originally posted by Chainmax
I understand, but the FAQ says that AVC in AVI doesn't allow implementation of some AVC features. What I don't fully understand is wether these limitations can appear at the encoding level (thus creating "broken" encodes) or just at the decoding level (so just using your suggestions would solve the problem.
It's on the decoding end. You can always demux H.264 from AVI, and the result is the same as if you put it in a different container to begin with.

I also have another question: I see that the H.264 specs include RDO and my question is wether H.264's RDO is identical to Xvid's VHQ or if there can be different approaches to RDO. Also, can Trellis be implemented in x264 or am I just talking nonsense?
No, the H.264 specs do not contain RDO. RDO is not something that can be specified in a standard. It's an encoding technique, and it could be applied to any lossy codec you've ever heard of. However, the H.264 format is very different from ASP, so fast RDO requires different tricks.
Trellis does not really apply to CABAC, and trellis for CAVLC is harder that for ASP.

[Chainmax]

Got it. I misread the FAQ when it said "RDO is not a tool defined by the AVC/H.264 specs....was first introduced by the H.264 reference software". Anyway, I don't know how hard would it be to implement VHQ in H.264, but what about leaving it as an option like in Xvid?

[stephanV]

that RDO comment is inappropriate there in the sticky... its confusing...

[RadicalEd]

x264 encoding support has just been patched into FFMPEG.

[Sharktooth]

New Pentium2 build available (no SSE) in the daily builds thread. I also added an Athlon Thunderbird build (no SSE).
Both use -ffast-math so please test them and report back if they crashes.

EDIT: P4 Prescott with SSE3 support build is also available.

[ivan_alias]

Originally posted by RadicalEd
x264 encoding support has just been patched into FFMPEG.

This is good news isn't it!

[springl]

x264 compilation by sharktooth, bobor, CD
From rev 144 on, I'm getting garbage a few frames after last I frame, with this settings:
default + update statsfile unchecked + max consecutive B-frames 1 + max reference frames 15 + deblocking unchecked.
Same settings + max reference frames 1 seems to be OK.
Here Athlon Thunderbird CPU + win98SE OS

Greetings
Springl

[IgorC]

rev164 doesn´t work full recompress in Virtual Dub. Only fast

[unmei]

this line from the changelog in the sticky should explain it:

(r164) VfW: reject YUY2 and RGB input formats

[planet1]

Originally posted by IgorC
rev164 doesn´t work full recompress in Virtual Dub. Only fast

from what I see there are two options (if source is not @ yv12):

either convert to yv12 via avisynth first,

or use Virtualdub 1.6.4 which has more colour depth options (setting output to YV12)

---> all recompression modes should work with x264 now

[dragongodz]

either convert to yv12 via avisynth first,
or use Virtualdub 1.6.4 which has more colour depth options (setting output to YV12)
and if you are using a different program ,not avisynth or virtualdub, that doesnt output yv12 ?

so what was the thinking behind making x264 only accept yv12 anyway ? seems a strange idea since most codecs accept multiple inputs.

[Ark]

Probably because x264 can't (yet i suppose) do RGB/YUY2/whatever to YV12 internal conversion.

[celtic_druid]

Revision 166:
revert 164. blame Spyder.

and for reference...
Revision 164:
VfW: reject YUY2 and RGB input formats

[dragongodz]

Probably because x264 can't (yet i suppose) do RGB/YUY2/whatever to YV12 internal conversion.
well thats strange since i just did a little test using RGB24 to x264 revision 150 and it not only encoded fine but played back fine with ffdshow(using libavcodec) fine aswell.

also how were people using earlier than 1.64 virtualdub versions and encoding fine ?

[EDIT]
revert 164. blame Spyder.
ahh so it should be back to accepting RGB and YUY2 then. cool.

[Sharktooth]

rev. 170 up.

[hpn]

Sharktooth, does your generic 170 build take advantage of the SSE optimization introduced the latest rev.170, or "generic" in this case means that there will be no speed improvement over 169? (I guess "SSE optimized chroma MC" in r170 means speed optimization only, but I maybe wrong). I don't know much about these CPU things, but always looking for the best build for my Atlhon XP that has SSE support. I also have no idea how celtic druid or bob0r compile their latest stuff (most likely generic too).

[Sharktooth]

I've compiled a SSE build too. Check it out.

[hpn]

Thanks!:)

[planet1]

Originally posted by dragongodz


also how were people using earlier than 1.64 virtualdub versions and encoding fine ?


its a VirtualDub 1.6.x glitch (1.5.x has a different colour handling) and also affects XviD & DivX:

http://forums.virtualdub.org/index.php?act=ST&f=15&t=9236&

[dragongodz]

virtualdub works in RGB in full processing mode, which is default so most people would actually be using it.

if you read above however you will see x264 does accept RGB and it has already been fixed back to being accepted.

[Yong]

Is the b_pyramid enable by default in x264vfw?
i got crashed decoding with ffdshow or mplayer if encode video using x264vfw...
The patch (libavcodec.bpyramid.7z)by Celtic druid doesn't work for me, strange.:(
BTW my own compile x264.exe cannot run,
when i execute it, i got "something entry point not found" then it closed.
(sorry, can't remember the message...)

[Sergejack]

I got a recurrent bug with the 170 rlz.

the ecnode just screw a part, then the vidéo get desync.

[Yong]

After reading the mplayer man page, b_pyramid=use b-frames as reference frame:rolleyes:
Why the name in vfw isn't same as mencoder?
It's make newbies confusing:(
After turn it off everything went fine:D

Here's the error message went i execute the x264vfw:
x264.exe - Entry point not found
The procedure entry point AVIFileExit cound not be located in the Dynamic link library MSVFW.DLL
What's wrong with it?
previous revision doesn't have this problem.

X264 development is very fast, now already r174, great:)

[virus]

Originally posted by Yong
After reading the mplayer man page, b_pyramid=use b-frames as reference frame:rolleyes:
Why the name in vfw isn't same as mencoder?
It's make newbies confusing:(
This is a deliberate choice.
Keep in mind that most n00bs out there approach the codec for the first time through VfW without knowing absolutely nothing about mencoder (which is still a tool for advanced encoding users like us :)).
So they should familiarize themselves with the term "reference" which is already a popular one (especially for AVC), instead of the pyramid thingie that, granted, sounds cool but also very very technical.
So technical that, for example, I've never heard sysKin using this name before akupenguin introduced it, despite the fact that on the topics of motion estimation and frametype decision, sysKin knows one or two things more than all of us ;)

Anyway, usually in VfW the names try to be as simple and direct as possible.

x264.exe - Entry point not found
The procedure entry point AVIFileExit cound not be located in the Dynamic link library MSVFW.DLL
Something is wrong here. This has something to do with bobololo's patch for AVI/AVS input in x264.exe afaict, though I've never heard of such problems. In fact the patch works ok for me, and mind you I'm on Win98SE. So if it works for me, it should work for everyone :)
(btw I have a library called msvfw32.dll *not* msvfw.dll, and I've been told that the name msvfw32.dll seems to be the right one under both 9x and NT kernels... are you sure you didn't screw up things? and which is the last revision which worked for you?)

[scorpdt]

I hope this is the right place to post my problem .... as I am not sure whether the problem lies with x264 codec or the mencoder itself.

The issue being ....

I have a movie which is 3 hours long, it is my plan to encode the whole movie using mencoder (MeGUI) into 2 CD. I had the audio encoded separately into aac_he 6 channel. Feeding the avs script and audio into MeGUI returned me the projected video bitrate of 886 kbit/s (I trust that value).

Before embarking on the whole movie encoding, I did a small sampling of 900 frames (using Trim in avs script) of a specific scene (music video) and run an Automatic 2 Pass @ 886Kbps bitrate (see attached log file (http://www.logisticshub.com/uploads/misc/VZ-Log1.txt)) and also the output AVI file (http://www.logisticshub.com/uploads/misc/VZ-900Frames-886Kbps.avi).

Next I did another sampling of 12255 frames (adding 11355 frame to the above) and run an Automatic 2 Pass @ 886kbps (see attached log file (http://www.logisticshub.com/uploads/misc/VZ-Log2.txt)) and also the output AVI file (http://www.logisticshub.com/uploads/misc/VZ-12255Frames-886Kbps.avi)(44MB).

Now should you are to compare the output you would expect the 1st 900 frames of the 2nd encoding would be close to the 1st sampling did above .... but they are not. The quality of the 1st 900 frames in the 2nd encoding is much much lower. Should you are to look at the skyline there are a lot of block pixels which points to lower bitrate. I did a cut-out of the 1st 900 frames using VDM and save the cut-out AVI file out (http://www.logisticshub.com/uploads/misc/VZ-0-900Frames-886Kbps.avi). Loading the cut-out file back on VDM, I found the average bitrate is 401kbps.

I am not sure what influence the kind of output I am getting .... so can someone help analyze and probably determine where the problem lies ... x264 or mencoder?.

FYI, I am using the latest x264 (build 177) and latest mencoder (dev-CVS-050315) ... the same problem happens on earlier builts for both.

Lastly, my apology if my explaination above confuses you. But please look at the files (both the log and AVI file) to understand the problem I mentioned above and please post you thought and possible solution.

Cheers!
Scorpio

[Ghim]

Originally posted by scorpdt
I hope this is the right place to post my problem .... as I am not sure whether the problem lies with x264 codec or the mencoder itself.

The issue being ....

I have a movie which is 3 hours long, it is my plan to encode the whole movie using mencoder (MeGUI) into 2 CD. I had the audio encoded separately into aac_he 6 channel. Feeding the avs script and audio into MeGUI returned me the projected video bitrate of 886 kbit/s (I trust that value).

Before embarking on the whole movie encoding, I did a small sampling of 900 frames (using Trim in avs script) of a specific scene (music video) and run an Automatic 2 Pass @ 886Kbps bitrate (see attached log file (http://www.logisticshub.com/uploads/misc/VZ-Log1.txt)) and also the output AVI file (http://www.logisticshub.com/uploads/misc/VZ-900Frames-886Kbps.avi).

Next I did another sampling of 12255 frames (adding 11355 frame to the above) and run an Automatic 2 Pass @ 886kbps (see attached log file (http://www.logisticshub.com/uploads/misc/VZ-Log2.txt)) and also the output AVI file (http://www.logisticshub.com/uploads/misc/VZ-12255Frames-886Kbps.avi)(44MB).

Now should you are to compare the output you would expect the 1st 900 frames of the 2nd encoding would be close to the 1st sampling did above .... but they are not. The quality of the 1st 900 frames in the 2nd encoding is much much lower. Should you are to look at the skyline there are a lot of block pixels which points to lower bitrate. I did a cut-out of the 1st 900 frames using VDM and save the cut-out AVI file out (http://www.logisticshub.com/uploads/misc/VZ-0-900Frames-886Kbps.avi). Loading the cut-out file back on VDM, I found the average bitrate is 401kbps.

I am not sure what influence the kind of output I am getting .... so can someone help analyze and probably determine where the problem lies ... x264 or mencoder?.

FYI, I am using the latest x264 (build 177) and latest mencoder (dev-CVS-050315) ... the same problem happens on earlier builts for both.

Lastly, my apology if my explaination above confuses you. But please look at the files (both the log and AVI file) to understand the problem I mentioned above and please post you thought and possible solution.

Cheers!
Scorpio

When you do a 2-pass encoding, you get a variable bitrate video, which is perfectly fine. It's up to the encoder and its rate control to give more or less bitrates for the different parts of the video. On the 12255 encode, the codec probably estimated that some parts after the 900 first frames required more bitrate (due to higher temporal or spatial complexity by example). That's why you get a lower bitrate (401 kbps) on the 900 first frames...
There is no problem at all in this behaviour....

[Sharktooth]

Try lowering the bitrate variability and see if it helps.

[scorpdt]

Thanks Ghim .... I aware that is what 2-pass encoding does, but could not figure out why the variation is so great. In fact I just completed encoding the 12255 frames sampling on Nero Recode (6 ref, 0 b-frame, cabac, macroblock,deblocking, chroma optimize and adaptive [auto smooth])and the result is comparable to that of the 1st sample I did except that Nero takes 2 hours to encode. BTW, should you look at the 1st pass of job2-1 i.e. the 2nd sampling, the it returns 2463.8 kbps ... so? Perhaps there might be a way to control this variation and this points to what Sharktooth suggest "lowering the bitrate variability .... so pardon me Sharktooth for my ignorance .... how do you do that .... which parameter must I tweak.

Thanks in advance.

Cheers!
Scorpio

[baer999]

I can see that x264 is still in development, but my question is if Nero Digitals 264er codec will become better or do they stop their development, because I haven't heard of them for quite a long time !

[IgorC]

it just simply says : bitrate varibiality 60% as default.

[Sharktooth]

Uhm, in mencoder it should be the ratecontrol sensitivity option.

[scorpdt]

Thanks IgorC .... saw that on VDM.

Sharktooth ... on mencoder i.e. via MeGUI ... that setting is disable for Automated 2pass .... perhaps Doom9 can help reason out why it is disable.

I doing another encode on VDM (should have thought about this earlier)

Cheers!
Scorpio

[Doom9]

from the mencoder manpage:
rc_sens=<0−100> (CBR only)
ratecontrol sensitivity (default: 4)
So, I have my doubts that this setting even corresponds to the bitrate variability setting in the VfW.

I think qcomp=<0−1>
quantizer compression (default: 0.6).
Corresponds to variability in the VfW.. the value and range matches, and quantizer compression basically does limit the bitrate variability. If you look at the manpage description of this switch:
This affects the ratecontrol: a lower value makes the bitrate more constant, while a higher value makes the quantization parameter more constant.And this setting is not disabled in any mode.

[Sharktooth]

Yes, it's the qcomp without any doubts :)

[virus]

yes, the equivalent of VfW's "bitrate variability" is called "qcomp" in mencoder, and qcomp = bitrate_variability / 100; in fact qcomp defaults to 0.6.

BTW mencoder's options are explained very clearly in Mplayer's documentation (http://www.mplayerhq.hu/DOCS/man/en/mplayer.1.html) ;)

EDIT: I hope noone will complain that choosing "bitrate variability" as a descriptive name for the option in VfW is confusing n00bs...

[scorpdt]

Thanks Guys it is clear.... get much better output from VDM with BV@ 0.15.
Trying out mencoder now via MeGUI with qcomm @ 0.2.

Cheers!
Scorpio

[Yong]

Originally posted by virus
...Anyway, usually in VfW the names try to be as simple and direct as possible.
Sorry for the late reply...
actually it was too simple for me :D
x264vfw don't have doc, don't have tool tips...
The doc is at Mplayer man page....

Something is wrong here. This has something to do with bobololo's patch for AVI/AVS input in x264.exe afaict, though I've never heard of such problems. In fact the patch works ok for me, and mind you I'm on Win98SE. So if it works for me, it should work for everyone :)
(btw I have a library called msvfw32.dll *not* msvfw.dll, and I've been told that the name msvfw32.dll seems to be the right one under both 9x and NT kernels... are you sure you didn't screw up things? and which is the last revision which worked for you?)
Sorry, typo:rolleyes:,
it's msvfw32.dll...
I'm on WinXP SP1,
I won't touch the source code, before i compile x264,
I thinks r15x... of x264.exe work for me...
recently i have many many problem with my own compiled x264vfw,
example:
1. it doen't shown up the "about" window when i click the x264vfw about button at VD/MOD and tmpgenc....
2. When i try to encode video using CBR mode or Constant Quant mode,
x264vfw pop-up a "console message": "could not find x264 2 pass stats file...":eek:
CBR or Constant quant need 2pass stats file?
3. the "console message" window too small,the "OK" and "Cancel" button were "truncated"...

[virus]

@Yong:

I have no clue about your problems, except for a single thing which may or may not be related.
You said that r15x worked for you and then you had problems. Well, I had some problems with mencoder+x264 around rev 150 or 151 too: mencoder kept crashing each time I started an encode. The "culprit" was apparently MingW 3.1+gcc 3.2.3 I was using. I updated to 3.2RC3+gcc 3.4.2 and everything worked again. Maybe you're using an old gcc too?

[Yong]

Originally posted by virus
@Yong:

I have no clue about your problems, except for a single thing which may or may not be related.
You said that r15x worked for you and then you had problems. Well, I had some problems with mencoder+x264 around rev 150 or 151 too: mencoder kept crashing each time I started an encode. The "culprit" was apparently MingW 3.1+gcc 3.2.3 I was using. I updated to 3.2RC3+gcc 3.4.2 and everything worked again. Maybe you're using an old gcc too?
I think i must update the Msys and Mingw32..
I never encountered crash with encoding mencoder+x264, when i was start compiling x264(start form r15x) and mplayer myself,
execpt some compiling problem with mplayer.
I will post the result on tomorrow(may be)...:)

[Yong]

@virus:
After upgraded to MinGW-3.2.0-rc-3 and binutil , all problem are gone except first problem(see my last post),
But still can view the "about" window via resource hacker:)

[Sergejack]

I've got a buggy video that crashes players.

http://users.skynet.be/EAF/naruto_39op30fpsV2ns.avi

params :
up to 4 B-frame, usable as reference; spacial prediction.
min max IDX : 100-1000
3 pass , first one not turned to fast mode.

[skal]

Hi,
Originally posted by Sergejack
I've got a buggy video that crashes players.

This bitstream seems to overflow picture buffer capacity (DPB_Size)...

-Skal

[ksnif]

Hi,

I've noticed that there is a native decoder missing from the x264 distribution. There is a decoder in the source code, but as the developers say, it is "unusable". Is there a reason for leaving the decoding side behind? is ffdshow covering all decoding needs?

I'd like to contribute to x264's development (if I'll ever find some free time). I see that the "decoder" is part of the todo list, so I could look at that (I think...). I need the standard though. Does the development team have a copy of this or is it up to me to purchase it?

regards

keep up the good work!

[bond]

ksnif, you might want to join #x264 on irc.freenode.net :)

[ksnif]

:) thanks

[Leo 69]

Has the development stopped ?

[Manao]

Not at all. It just happens that Aku / Loren is away for a week. Development should resume ASAP after his return, i think.

[Neo Neko]

Originally posted by ksnif
Hi,

I've noticed that there is a native decoder missing from the x264 distribution. There is a decoder in the source code, but as the developers say, it is "unusable". Is there a reason for leaving the decoding side behind? is ffdshow covering all decoding needs?

I'd like to contribute to x264's development (if I'll ever find some free time). I see that the "decoder" is part of the todo list, so I could look at that (I think...). I need the standard though. Does the development team have a copy of this or is it up to me to purchase it?

regards

keep up the good work!

FFmpeg/ffdshow is pretty much covering all the decoding needs as you put it. But that should't bar you from trying. There are a few things ffdshow is not yet doing IIRC. Like automatic post processing. You can set it manually. But IIRC it is supposed to do it automatically according to flags in the bitstream.

[MSlv]

There hasn't been a new build for some time now. Should we blame the lack of developers? Or the new builds aren't public yet?

[Sirber]

code is on the SVN and the SVN is public. I'd say lack of dev :(

[Manao]

MSlv : look my answer two posts up.

Neo Neko : what you call automatic postprocessing is in fact adding the noise removed by the encoding during the decoding. It just has been normalized, it is part of the high profile, and it needs the encoder to analyse that noise during the encoding process.

So for the moment, FFDShow / ffmpeg is up to date, since no encoders that i know of support such 'noise' flags.

Edit : up to date, in that regard, of course. It lacks interlacing and high profile support, the first one being a living nightmare, while the second is really promosing

[MSlv]

Originally posted by Manao
MSlv : look my answer two posts up.
Sorry. I should've payed more attention and read the posts.

So new builds should be out soon. cool.
Thanks

[hpn]

Nice to see the x264 development is still alive (rev.179), although the future role of akupenguin still remains a mistery, at least for me.

[ksnif]

Hi everyone,

I'm trying to build libx264.dll using MS VS 6. I get the following error:

../..\common/common.h(278) : error C2485: 'align' : unrecognized extended attribute

actually I get several of these errors about "align". is there something I should include/copy ? I use cygwin's nasm. Is that a problem?

thanks in advance!

[Sharktooth]

If you have cygwin why don't you use gcc for building x264?

[ksnif]

Originally posted by Sharktooth
If you have cygwin why don't you use gcc for building x264?

I'm relatively new in software development, so I'm not very familiar with the tools. I actually use the GNU tools rather than MS's ones. I'll try to compile the dll with gcc. if you have any useful tips for me that would be nice :)

...that’s kind of embarrassing. I want to contribute to x264 project and I can not seem to get the compilation state right!:rolleyes:

[Sharktooth]

Try with revision 180 and MSVC.
However if you look at the x264 daily builds thread you will find all the info you need to compile x264 with gcc.

[ksnif]

Originally posted by Sharktooth
Try with revision 180 and MSVC.
However if you look at the x264 daily builds thread you will find all the info you need to compile x264 with gcc.

Thank you Sharktooth. I never looked further down that thread. being a sticky I though it wouldn't have anything else. I've already build the dll with gcc (didn't test it though yet). I've just tried now revision 180 with MSVC but I get the same error. I must be forgetting something.

Thanks again!:)

[akupenguin]

Originally posted by ksnif
I'd like to contribute to x264's development (if I'll ever find some free time). I see that the "decoder" is part of the todo list, so I could look at that (I think...). I need the standard though. Does the development team have a copy of this or is it up to me to purchase it?
You can download it from ITU (http://www.itu.int/rec/recommendation.asp?type=folders&lang=e&parent=T-REC-H.264) (Yes it's a store, but they give you 3 free recs annually (http://www.itu.int/publications/bookshop/how-to-buy.html#free))

[Sagittaire]

with rev 179 bref work well for me ... thanks Manao

Edit: Playback is good but quality is not better ...

[bond]

Originally posted by akupenguin
You can download it from ITU (http://www.itu.int/rec/recommendation.asp?type=folders&lang=e&parent=T-REC-H.264) (Yes it's a store, but they give you 3 free recs annually (http://www.itu.int/publications/bookshop/how-to-buy.html#free)) i also link to a version of the specs in the mpeg-4 info sticky

[hpn]

I just got curious and downloaded the 1864049 bytes PDF recommendation approved in 2003-05, but the ITU site reports a "superseded" status for this particular version. Akupenguin, is this the document that you are using when coding x264 or there is a newer one? I can see that the "in force" version approved in 2005-03 is yet to be published. Probably the Bond's draft version linked in the sticky is even older, but the PDF is damaged and won't open so I couldn't check.

[akupenguin]

The newer version (that's not published yet) only differs in that it contains high profile. For x264, I use the version I linked (which is 2004-05).

[ac-chan123]

i have found an other h.264 implementation(decoder only).
you can find the source and the papers at :
http://www-user.tu-chemnitz.de/~mfie/stuff/SA/

maybe it gove you a new idea. The paper h264-pres.pdf is german but h264-paper.pdf is english. The source it self seams not be commened.

[baer999]

Oh I am so happy that the coding on the codec are still going on, I thought that it would be the end when one of the best coders went to Nero... but now there come new releases every day like a month ago ! That's great and I hope there will be some good coders which will take part in this project, I can only VB6, HTML, PHP, Delphi but I can't C++... what have I learn to, to help the project ? When I can C++ I doesn't know really much about video coding, so can anyone give me a hint ? thx

[defunkt]

I'm finding the following PDF's a very useful starting point...

www.vcodex.com/h264.html (http://www.vcodex.com/h264.html)

[baer999]

OK thx now I can see the way it goes. When I could C++ and understand the way it is going, then i could help at the coding work or is there any other part I must learn or know ?

[zombi55]

Hi

I have a small request to make! Could you nicely add a key "DisplayVersion" with the n° of the version (rev), the build or the core

Ty

Zombi55 :)

[TripleA]

Originally posted by baer999
Oh I am so happy that the coding on the codec are still going on, I thought that it would be the end when one of the best coders went to Nero... but now there come new releases every day like a month ago ! That's great and I hope there will be some good coders which will take part in this project, I can only VB6, HTML, PHP, Delphi but I can't C++... what have I learn to, to help the project ? When I can C++ I doesn't know really much about video coding, so can anyone give me a hint ? thx

If open source projects died when one developer ceased working on them, for whatever reason, the whole concept would have ceased to exist long ago.

The very idea of open source is to facilitate transition from one generation of developers to the next with as little disturbance as possible so that good code will live on after it's abandoned by its original coder(s), for whatever reason(s).

Unlike closed source: take Xing MPEG Player as an example; this thing was written way back at the dawn of the MPEG age in 1997, yet it's still in use today in the local market around me. The reason? It works. Does its job better than anything else. Excellent code. Never to be built on because it's closed source. Sad.

As to the situation with former x264 devs, hey! look at the bright side: Nero's CODEC will soon get so much better and this will: a) provide more choices for users and b) provide some healthy competition for the open source developers.

;)

[Stacey Melissa]

Is it bad when the first pass returns negative kbit and size values? I've been messing around with the qp_constant parameter in an attempt to get it reasonably close to my target bitrate on the second pass, as suggested in the mencoder command documentation.

My encoding batch file works with 1000 frame clips of the same movie (The Matrix), but returns negative kbit and size when the whole movie is encoded.

I'm using CD's March 15 AthlonXP compile of mencoder.

The mencoder commands in my encoding batch file:

mencoder "The Matrix.avs" -noaspect -aspect 16:9
-ovc x264 -o NUL: -passlogfile "The Matrix - mencoder.log"
-x264encopts pass=1:frameref=2:bframes=5:nob_pyramid:4x4mv:
deblockalpha=-1:deblockbeta=-1:log=0:noweight_b:nochroma_me:
rc_buffer_size=3600:qp_constant=16

mencoder "The Matrix.avs" -noaspect -aspect 16:9
-ovc x264 -passlogfile "The Matrix - mencoder.log"
-x264encopts pass=2:frameref=2:bframes=5:nob_pyramid:4x4mv:
deblockalpha=-1:deblockbeta=-1:log=0:noweight_b:nochroma_me:
rc_buffer_size=3600:bitrate=1800
-o "The Matrix.264" -of rawvideo


The source AVS, from which I've made several successful encodes using other mencoder params:

LoadPlugin("C:\PROGRA~1\4ceCore\DGMPGDec\DGDecode.dll")
LoadPlugin("C:\PROGRA~1\4ceCore\AviSynthPlugins\UnDot.dll")

mpeg2source("D:\Documents and Settings\All Users\Documents\
My Videos\DVD\The Matrix\The Matrix.d2v")

trim(62,195915)

crop(0,62,720,352)

Undot()

And here's the output of my batch file, halfway through the second pass, with the weird part in italics:

Encode x264 video and AAC audio
Movie title: The Matrix
Bitrate [kbps]: 1800
Set advanced parameters? [y/n]: n

Encoding first pass ...
06:52 PM
MEncoder dev-CVS-050315-21:28-3.4.2 (C) 2000-2005 MPlayer Team
CPU: Advanced Micro Devices Athlon 4 /Athlon MP/XP Palomino (Family: 6, Stepping
: 2)
Detected cache-line size is 64 bytes
CPUflags: Type: 6 MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 0 SSE2: 0
Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE

File not found: 'frameno.avi'
Failed to open frameno.avi
success: format: 0 data: 0x0 - 0x114
AVS file format detected.
VIDEO: [YV12] 720x352 12bpp 23.976 fps 0.0 kbps ( 0.0 kbyte/s)
[V] filefmt:38 fourcc:0x32315659 size:720x352 fps:23.98 ftime:=0.0417
Opening video filter: [expand osd=1]
Expand: -1 x -1, -1 ; -1 (-1=autodetect) osd: 1
==========================================================================
Opening video decoder: [raw] RAW Uncompressed Video
VDec: vo config request - 720 x 352 (preferred csp: Planar YV12)
Could not find matching colorspace - retrying with -vf scale...
Opening video filter: [scale]
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
SwScaler: using unscaled Planar YV12 -> Planar YV12 special converter
Selected video codec: [rawyv12] vfm:raw (RAW YV12)
==========================================================================
Writing AVI header...
ODML: vprp aspect is 16384:9193.
ODML: vprp aspect is 16384:9193. Trem: 0min 0mb A-V:0.000 [0:0]
ODML: Starting new RIFF chunk at 0MB.: 0min 0mb A-V:0.000 [2294:0]
ODML: Starting new RIFF chunk at 1023MB. 0min 0mb A-V:0.000 [2474:0]
Pos:8168.6s 195855f ( 0%) 5fps Trem: 0min 0mb A-V:0.000 [-1678:0]
Flushing video frames

Writing AVI index...
Fixing AVI header...
ODML: vprp aspect is 16384:9193.

Video stream: -1678.254 kbit/s (-209781 bps) size: -1713664313 bytes 8168.794
secs 195855 frames

Encoding second pass ...
06:50 AM
MEncoder dev-CVS-050315-21:28-3.4.2 (C) 2000-2005 MPlayer Team
CPU: Advanced Micro Devices Athlon 4 /Athlon MP/XP Palomino (Family: 6, Stepping
: 2)
Detected cache-line size is 64 bytes
CPUflags: Type: 6 MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 0 SSE2: 0
Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE

File not found: 'frameno.avi'
Failed to open frameno.avi
success: format: 0 data: 0x0 - 0x114
AVS file format detected.
VIDEO: [YV12] 720x352 12bpp 23.976 fps 0.0 kbps ( 0.0 kbyte/s)
[V] filefmt:38 fourcc:0x32315659 size:720x352 fps:23.98 ftime:=0.0417
Opening video filter: [expand osd=1]
Expand: -1 x -1, -1 ; -1 (-1=autodetect) osd: 1
==========================================================================
Opening video decoder: [raw] RAW Uncompressed Video
VDec: vo config request - 720 x 352 (preferred csp: Planar YV12)
Could not find matching colorspace - retrying with -vf scale...
Opening video filter: [scale]
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
SwScaler: using unscaled Planar YV12 -> Planar YV12 special converter
Selected video codec: [rawyv12] vfm:raw (RAW YV12)
==========================================================================
Writing AVI header...
Pos:3337.0s 80013f ( 0%) 7fps Trem: 0min 0mb A-V:0.000 [1680:0]

[Sirber]

CPUflags: Type: 6 MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 0 SSE2: 0
Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE
Could be that. From what I see, your Athlon XP doesn't have SSE, and your mencoder id compiled for it.

[Sharktooth]

Every athlon xp have SSE.

[Stacey Melissa]

I've done quite a few encodes with this build, but I've never noticed any issues with it before. In any case, the encode seems to have worked quite beautifully. So no obvious problems. Now I just wonder whether there is anything lurking beneath the surface. That, plus I wonder whether I should still work on adjusting qp_constant to get it closer to the target bitrate, given that I don't know what the real first pass bitrate turned out to be.

[hellfred]

Originally posted by Sirber
Could be that. From what I see, your Athlon XP doesn't have SSE, and your mencoder id compiled for it.
If you have enough bitrate to get a bootable Linux CDRom or a linux OS installed on your system, try to boot from Linux and check mplayers output. It will then deteced the correct instruction sets for your system. IIRC SSE was disabled on win32 due to some problems with this instruction set. At least my PIII will only output SSE when booted to linux, but not to win32.

Hellfred

[Manao]

Since SSE isn't used in the encoder, it won't be a problem if it's not correctly detected. The instruction sets that really matter are MMX and MMXEXT / iSSE.

Edit : sorry, i was of topic, i thought you were speaking of x264, not mencoder...

[Holy]

I have one question, maybe it has been answered in any way, but I could not find it:

I downloaded the latest build ( X264VFW_rev184_p3 ) and could use it via virtual dub like any divx, xvid and co. I encoded some material but did not install anything for decoding, just have the NeroDecoder for 264 content and it worked, the material starts fine on zoomplayer, but the decoding itself and the image has many many failures, moving pixels and so on. Is it because Nero doesn't decode it correctly or is it because of the very early build of this codec?

Is there any x264-only-decoder? I tried ffdshow once for snow decoding and it worked, but all the other codecs, materials and so on were influenced too much and I also don't want any decoder to come in conflict with the NeroDecoder for 264 content when it comes to Recode content.

Thanks for your help :)

[Stacey Melissa]

@Holy - I've had issues with Nero's filter when trying to play back x264 content from AVI. It works well in .mp4 container, though. You'll have to extract to raw .264 stream using avi2raw and then mux the raw stream into .mp4 with mp4creator. Both are part of MPEG4IP tools (http://www.aziendeassociate.it/cd.asp?dir=/mpeg4iptools). Do a search to find out how to use them.

[akupenguin]

Originally posted by Stacey Melissa
Is it bad when the first pass returns negative kbit and size values? I've been messing around with the qp_constant parameter in an attempt to get it reasonably close to my target bitrate on the second pass, as suggested in the mencoder command documentation.
The error is only in MEncoder's UI. It doesn't affect the operation of x264.
To see the actual bitrate, run countquant_x264 (http://students.washington.edu/lorenm/src/x264/countquant_x264.pl) on the statsfile. (Also works for vfw 1st pass)

[Stacey Melissa]

Thanks, akupenguin. That's just the functionality I was needing! Now I'll just have to learn a little Perl to convert it to something my Windows box can use. No biggie - the code looks quite simple, and I've been wanting to pick up some Perl for quite awhile now. :)

[Sharktooth]

Easier solution: download and install Active perl (http://www.activestate.com/Products/Download/Download.plex?id=ActivePerl)

[Stacey Melissa]

Thanks, Sharktooth! That works even better. Looks like I'll have to increase my qp_constant a bit, because that -1678.254 kbit/s was actually a 2527.95 kbit/s first pass. :D

[virus]

Originally posted by akupenguin
To see the actual bitrate, run countquant_x264 (http://students.washington.edu/lorenm/src/x264/countquant_x264.pl) on the statsfile.
Thanks for this one.

But just a note:
All: 1000 avgQP:21.77 avgBits: 2513
I: 16 ( 1.6%) avgQP:18.69 avgBits:22376
P: 283 (28.3%) avgQP:20.83 avgBits: 4836
B: 701 (70.1%) avgQP:22.22 avgBits: 1122

total size: 2513611 = 2.40 MiB = 482.13 kbps @ 23.976 fps
how can 1000 frames at 2513 avgBits sum up to a total of 2.4 MB? I assume you meant bytes not bits?

Also... feature request :D
what about modifying the output this way?
total size: 2513611 bytes = 2454.70 KiB = 2.40 MiB
bitrate: 482.13 kbps @ 23.976 fps = 502.72 kbps @ 25 fps =
602.66 kbps @ 29.97 fps

(that's too little of a change to send you a patch :))

virus

[akupenguin]

done.

[yaz]

Originally posted by Sharktooth
Easier solution: download and install Active perl (http://www.activestate.com/Products/Download/Download.plex?id=ActivePerl) sorry for the noobish interruption but ...
- what to download a/o install from there for winxp ?
- would someone make a win32 exe from it ?
- is there sg similar for xvid ? ( i would love that too)

thx
y

[virus]

MSYS users should be able to launch countquant_x264 by simply typing "perl countquant_x264.pl <statsfile>" at the prompt. If it doesn't work, then Perl is probably a part of MSYS-DTK (http://prdownloads.sourceforge.net/mingw/msysDTK-1.0.1.exe?download) and you'll need to install it.

MSYS-DTK is an integration to MSYS which allows to run powerful configuration scripts. It's not required for compiling x264 nor XviD 1.0.x, but apparently it's needed for XviD 1.1.x (that's why I installed it while ago). Probably other projects need it too. So if you like to build your own code, I'd definitely recommend it.

[Stacey Melissa]

Would there be any way to enforce a max bitrate on 2pass encodes? My Athlon XP 1800 chokes on playback when the bitrate spikes above 8500 kbps, so I'd like to be able to set that as a bitrate ceiling. That would also give more leeway to play around with the qcomp value, since I wouldn't have to worry about spikes when increasing qcomp.

[Sharktooth]

The VBV options are not exposed in the VFW interface :( so, i think the only way to do that is thru mencoder or the CLI.

[Stacey Melissa]

That doesn't bother me, since I use mencoder anyway. ;)

[Sagittaire]

Originally posted by Stacey Melissa
Would there be any way to enforce a max bitrate on 2pass encodes? My Athlon XP 1800 chokes on playback when the bitrate spikes above 8500 kbps, so I'd like to be able to set that as a bitrate ceiling. That would also give more leeway to play around with the qcomp value, since I wouldn't have to worry about spikes when increasing qcomp.

IMO lower variablity can solve your problem ...

[Doom9]

i think the only way to do that is thru mencoder or the CLI.VBV in mencoder? Gotta read that manpage again.. I have the lingering feeling that there are quite a few parameters that haven't been in there when I started coding.

[Stacey Melissa]

Originally posted by Sagittaire
IMO lower variablity can solve your problem ...
Yes, it would solve the bitrate spike problem if I used a lower qcomp, but it would do so at the expense of good bitrate distribution.

Originally posted by Doom9
VBV in mencoder? Gotta read that manpage again.. I have the lingering feeling that there are quite a few parameters that haven't been in there when I started coding.
I check the mencoder manpage for new options every day. It's not in there. I'd notice it if it were. :D IIRC, (no)b_pyramid was the most recent option added to the manpage.

[Sharktooth]

in CLI you have this:
--rcsens <integer> CBR ratecontrol sensitivity [10]
--rcbuf <integer> Size of VBV buffer [0]
--rcinitbuf <integer> Initial VBV buffer occupancy [0]
--rceq <string> Ratecontrol equation ["blurCplx^(1-qComp)"]
--qcomp <float> 0.0 => CBR, 1.0 => CQP [0.60]
--cplxblur <float> reduce fluctuations in QP (before curve compression) [20.0]

Don't know if all those options are in mencoder too...

[Doom9]

scenecut and b_sens wasn't there in my original manpage.

rc_init_buffer sounds very much like rcinitbuf, but in mencoder it only seems to apply to CBR, qcomp and cplxblur is there as well, rcbuf seems to correspond to rc_buffer_size but no mention that of VBV. Did somebody forget to mention that in the manpage? Except for rceq all the parameters you mentioned seem to be there, just under a different name.

[celtic_druid]

Last new options added to mencoder were chroma_me and chroma_qp_offset. That was 4 weeks ago.
http://www1.mplayerhq.hu/cgi-bin/cvsweb.cgi/main/libmpcodecs/ve_x264.c