x264 development

[b66pak]

i tried this of course...it generate an empty file...check the dos output!!!

my line:
x264.exe "hfyu_VTS_03_1-001_Track1.avi" --bitrate 1000 --keyint 25 --level 3
--min-keyint 1 --deblock 1:1 --no-cabac --psy-rd 0.6:0 --partitions p8x8,b8x8,i4x4
--vbv-bufsize 10000 --vbv-maxrate 10000 --threads auto --thread-input --aq-mode 0
--sar 1:1 --aud --progress --no-psnr --no-ssim --deldup minfps 1
--timecode "hfyu_VTS_03_1-001_Track1.avi.ABR.VFR.mkv_timecodes_v2.txt"
--output "hfyu_VTS_03_1-001_Track1.avi.ABR.VFR.mkv"
>"hfyu_VTS_03_1-001_Track1.avi.ABR.VFR.mkv_log.log"


dos window:
F:\Tools_Video\direct264_20090320>x264.exe "hfyu_VTS_03_1-001_Track1.avi" --bitr
ate 1000 --keyint 25 --level 3 --min-keyint 1 --deblock 1:1 --no-cabac --psy-rd
0.6:0 --partitions p8x8,b8x8,i4x4 --vbv-bufsize 10000 --vbv-maxrate 10000 --thre
ads auto --thread-input --aq-mode 0 --sar 1:1 --aud --progress --no-psnr --no-ss
im --deldup minfps 1 --timecode "hfyu_VTS_03_1-001_Track1.avi.ABR.VFR.mkv_timeco
des_v2.txt" --output "hfyu_VTS_03_1-001_Track1.avi.ABR.VFR.mkv" 1>"hfyu_VTS_03
_1-001_Track1.avi.ABR.VFR.mkv_log.log"
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Slow Slow_mod4_stack
x264 [info]: profile Baseline, level 3.0
x264 [info]: slice I:24 Avg QP:25.08 size: 31682
x264 [info]: slice P:576 Avg QP:27.55 size: 3036
x264 [info]: mb I I16..4: 13.2% 0.0% 86.8%
x264 [info]: mb P I16..4: 1.5% 0.0% 2.0% P16..4: 41.8% 13.7% 1.8% 0.0% 0
.0% skip:39.2%
x264 [info]: final ratefactor: 23.95
x264 [info]: kb/s:1002.9

encoded 600 frames, 22.78 fps, 1006.30 kb/s
_

[LoRd_MuldeR]

kemuri-_9 is right. That also explains why your file was empty.

BTW: A console window on a WinNT-based operating system is not related to DOS at all ;)

[b66pak]

thanks a lot...
_

[Hyrax]

Hello- I'm having problems with x264 crashing lately in Windows XP... it either dies silently or comes up with a memory exception. The problem seems to come mainly from squeezing very large HD videos (28 - 45 GB) to 8 GB. I'm going to do some memtests and other things to confirm it isn't a hardware related issue, but I'm relatively sure it isn't. What else can I do to pinpoint the problem?

Edit: I'm real new to using x264 and will appreciate any guidance. Thanks.

[Sagekilla]

It could be possible youre running out of memory. How much memory do you have and what's your script look like?

[kemuri-_9]

yes it does sound like you're running out of memory...
are you running the x64 or x86 version?
if the x86 one, you should answer Sagekilla's questions from above.

[Hyrax]

I'm using the x86 version and have 3 GB.
I'm doing a 2 pass encode. The first pass works fine. Here's the script for the 2nd pass (I added cr/lf to make it easier for you to read):
"C:\Program Files\x264\x264.exe" "C:\temp\Video\video1.avs" --pass 2 --bitrate 7623
--stats "C:\temp\Video\video1.stats" --sar 1:1 --level 4.0
--aud --nal-hrd --vbv-bufsize 25000 --vbv-maxrate 25000 --filter 0,0
--ref 3 --mixed-refs --bframes 3 --b-adapt 1 --weightb
--direct auto --subme 7 --trellis 1 --partitions all --8x8dct --me umh
--threads auto --thread-input --progress --no-psnr --no-ssim --output "C:\temp\video\video1.264"

I'll run it again and monitor memory. Thanks for the suggestion.

edit: as a side note, it takes approximately 2 hours for the first pass to complete nad it produces a 7 GB file from a 28 GB source.

[Sagekilla]

Please post your avisynth script too. We need to see the whole chain to see if anything is memory starved.

[Dark Shikari]

x264 could not possibly crash from a malloc failure; all mallocs are checked, and no memory allocation happens outside of the start of the program.

Of course, a decoder or Avisynth could be the culprit as well.

You're not going to get anywhere without some gdb.

[MasterNobody]

x264 could not possibly crash from a malloc failure; all mallocs are checked
Probably it would crash before this check because of:
void *x264_malloc( int i_size )
{
#ifdef SYS_MACOSX
/* Mac OS X always returns 16 bytes aligned memory */
return malloc( i_size );
#elif defined( HAVE_MALLOC_H )
return memalign( 16, i_size );
#else
uint8_t * buf;
uint8_t * align_buf;
buf = (uint8_t *) malloc( i_size + 15 + sizeof( void ** ) +
sizeof( int ) );
align_buf = buf + 15 + sizeof( void ** ) + sizeof( int );
align_buf -= (intptr_t) align_buf & 15;
*( (void **) ( align_buf - sizeof( void ** ) ) ) = buf;
*( (int *) ( align_buf - sizeof( void ** ) - sizeof( int ) ) ) = i_size;
return align_buf;
#endif
}

[Dark Shikari]

Probably it would crash before this check because of:Oh indeed, that, the memalign emulation hack for crappy systems like MinGW.

[kemuri-_9]

Oh indeed, that, the memalign emulation hack for crappy systems like MinGW.

heh, i still personally use my patch to utilize mingw's aligned memory methods, so i never see that emulation.

but it still would be wise to fix the issue....

[Hyrax]

Thanks for all your help. It is greatly appreciated.

Here's my Avisynth script:

#Video
video=DirectShowSource("C:\temp\video\video1.mkv",audio=false).ConvertToYV12()

#Audio
LoadPlugin("C:\Program Files\AviSynth plugins\NicAudio\NicAudio.dll")
audio=NicAC3Source("C:\temp\video1\audio1.ac3")
audio=ResampleAudio(audio,48000)



And, so you don't need to look it up, here's a copy of my x264
"C:\Program Files\x264\x264.exe" "C:\temp\Video\video1.avs" --pass 2 --bitrate 7623
--stats "C:\temp\Video\video1.stats" --sar 1:1 --level 4.0
--aud --nal-hrd --vbv-bufsize 25000 --vbv-maxrate 25000 --filter 0,0
--ref 3 --mixed-refs --bframes 3 --b-adapt 1 --weightb
--direct auto --subme 7 --trellis 1 --partitions all --8x8dct --me umh
--threads auto --thread-input --progress --no-psnr --no-ssim --output "C:\temp\video\video1.264"


I don't think I'm running out of memory; while watching usasge in Task Manager, x264 seems to be staying at ~820,000K and physical memory remains at ~1,690,000K.


CPU usage is high (90% or more), but temperatures for all four physical cores remain good at 65 degrees. I've got an i7 CPU, so it looks like I'm running 8 cores - is it possible that x264 doesn't like hyper-threading?

In the back of my mind I have a (unreasonable?) fear that Intel's new memory controller could be the trouble here. I'm going to try replacing the memory just in casae

I've got an older, slower computer that I use as a server. Just as a sanity check I'll try to see if I can reproduce this problem on that system, but the encoding will take about 24 hours.

[Hyrax]

x264 is now working for me and I may never know what the exact problem was. On a whim I decided to uninstall my ATI video drivers and then install their latest release. I tried to re-encode immediately after starting my computer and it worked. Usually I have my computer on for hours - watching and editing videos - before I start encoding. So I don't know if something gets left in memory that causes problems, or if the video drivers I was using were somehow interfering, or if I've got a bad memory chip that occasionally causes problems.

Whatever was wrong earlier, it does seem apparent that x264 is not causing the problem.

Thanks again for your assistance.

[LoRd_MuldeR]

Video drivers can't affect x264, as x264 doesn't use the GPU in any way (yet). Of course a borked driver may crash the entire system, but that's a different story.

Also it's impossible that "something left in memory" causes the problem, because all modern operating systems are running in Protected Mode (http://en.wikipedia.org/wiki/Protected_mode) ;)

But an overheating CPU or a borked memory module may cause problems indeed! I highly recommend that you check your system with Memtest86+ (http://www.memtest.org/#downiso) as well as Prime95 (http://www.freewarefiles.com/Prime95_program_19638.html).

[laserfan]

x264.exe options > logfile.txt...

as x264 outputs to stderr and not stdout the above would be 2> and not >....Thanks fellas, something else I didn't know (and I don't think this is in the --longhelp either). I suppose most .exes will do this?

Anyway, I've been PAUSEing my .cmd files then copy/pasting to a textfile. This will save me some fiddling! :)

[LoRd_MuldeR]

Thanks fellas, something else I didn't know (and I don't think this is in the --longhelp either). I suppose most .exes will do this?

It's not documented for x264, because it has nothing to do with x264 itself!

The ">" operator will redirect STDOUT to a file, just like the "2>" operator will redirect STDERR to a file, the "<" operator will feed a file into STDIN and the "|" operator will connect two applications.

These are shell operators and they work with any application that uses standard handles...

[laserfan]

The ">" operator will redirect STDOUT to a file, just like the "2>" operator will redirect STDERR to a file, the "<" operator will feed a file into STDIN and the "|" operator will connect two applications.

These are shell operators and they work with any application that uses standard handles...I guess since I'm being stupid I might ask why x264 outputs "info" (not errors) to STDERR. but doesn't to STDOUT, but no doubt I've already pushed my luck in this advanced thread! Thanks LM! :o ;)

[Dark Shikari]

I guess since I'm being stupid I might ask why x264 outputs "info" (not errors) to STDERR. but doesn't to STDOUT, but no doubt I've already pushed my luck in this advanced thread! Thanks LM! :o ;)All sane programs output info to stderr. If they outputted info to stdout, it would make it impossible to actually output data to stdout, because data and info would end up mixed.

[akupenguin]

All sane programs output info to stderr. If they outputted info to stdout, it would make it impossible to actually output data to stdout, because data and info would end up mixed.
That is indeed why x264 uses stderr. Though x264cli has no option to output video to stdout, it only applies with ffmpeg/mencoder/etc.

[laserfan]

Ouch. I should have figured that. Thanks for your indulgences. :)

[kemuri-_9]

That is indeed why x264 uses stderr. Though x264cli has no option to output video to stdout, it only applies with ffmpeg/mencoder/etc.

you must have forgotten that x264cli does output video to stdout with -o - (or --output -) as in

$ x264 foreman_cif_352x288.yuv -o - --crf 18 --quiet 1>video.h264

encoded 300 frames, 88.47 fps, 988.47 kb/s

$ mp4box -add video.h264 -new video.mp4
AVC-H264 import - frame size 352 x 288 at 25.000 FPS
Import results: 300 samples - Slices: 2 I 298 P 0 B - 1 SEI - 2 IDR
Saving video.mp4: 0.500 secs Interleaving

[vmrsss]

x264's nr operates directly on the inter residual, and quantizes dct coefficients more strongly when it estimates that they're probably noise. So it directly reduces bitrate in a way that you don't get if you just remove noise any old way and then ask the encoder to encode the resulting image at full precision.
The reuse of mvs is not just a speed optimization, it's part of the reason the denoiser works. Same for the use of dct, and in particular the same dct as x264 will choose for the encoding of that block.

so how would that compete/compare with avisynth filters? I was surprised to read your post, because --nr isn't something that is recommended nor publicized, I always had the impression that was because it is of pretty low quality. (I'm having a hard time to find a nice degrainer/noiser which does more than 2fps and doesn't completely blur the picture.)

[vmrsss]

Its not a replacement for avisynth NR, it can be used in conjunction with. Actually using lighter NR in avisynth and strong NR in x264 seems to be more beneficial in many cases bitrate and picture quality wise than being heavy handed with avisynth NR.

why would you use a light denoiser in avisynth in addition to a strong --nr? the former is dead slow, the latter is optimised, don't they perform the same task? I would be very happy to discover that --nr can serve my purpose of removing background noise from DVB captures...

[burfadel]

I find the benefit of the --nr is more picture optimisation than physical noise reduction, although there would have to be some noise reduction! I've tested it several times with different avisynth denoisers, its more bandwidth friendly, or seems that way, to use an --nr of say around 500 (seems to be a good value for the sources I tested), and lower avisynth filtering strength to keep the encoded size down whilst keeping really good picture quality and structure rather than the perceived benefits of scrubbing out detail using avisynth noise reduction and having roughly the same end bitrate used and a smeary picture without it.

The main thing is, give it a try with and without, inspect the picture quality and file size (say using CRF) as you go. The scale of NR is from 0 to 1000, try at least 300! Don't look too much in to SSIM etc, as NR is an internal x264 function, and NR is a function that removes noise, the SSIM of the output will naturally generally be lower as its not identical to the avisynth input! If you used an avisynth filter, you can smear and brutalise the picture as much as you want, but since x264 acts on the output from avisynth (thats the typical use so thats why I'm using that for the example), the SSIM can almost be perfect from input to output, as SSIM is a measure of x264 input vs output. The picture would still look botched though. So check it with your eyes, not by an input/output SSIM comparison, and choose which one you prefer :)

[akupenguin]

so how would that compete/compare with avisynth filters? I was surprised to read your post, because --nr isn't something that is recommended nor publicized, I always had the impression that was because it is of pretty low quality.
I didn't say nr was particularly good at removing noise without harming content, I just said it's better at reducing bitrate than an external filter of the same strength. If you're encoding at a high enough bitrate that the damage done by inaccurate denoising is worse than the damage done by extra quantization, then pick an avisynth filter that's optimized for quality rather than compression. And of course there's room for compromise too.

IOW, if you have less precise knowledge about some features of your input than others (because some are covered with noise), then you should quantize the former more than the latter, so as to maximize the similarity between the encoded stream and the unknown original input within any given bit budget. But that's no substitute for your best attempt at removing the noise too.

The scale of NR is from 0 to 1000
The scale of nr is 0 to 65536. 1000 is just a reasonable guess at what you might want to try so as not to completely destroy the content.

[Blue_MiSfit]

Correct me if I'm wrong, but it seems like NR has some pretty significant promise at reducing bitrate!

If it's using the motion vectors that x264's ME generates, it must have a lot of potential.

I wonder if something cooler like MVDegrain could be ported in??? Just a thought, I'm no coder :p

I might have to try this out on some uber low bitrate stuff (500kbps CBR high complexity 480p)

~MiSfit

[b66pak]

how can be properly decoded the new x264 lossless mode?

the problem is described here:

http://forum.doom9.org/showthread.php?p=1283664#post1283664
_

[Dark Shikari]

how can be properly decoded the new x264 lossless mode?

the problem is described here:

http://forum.doom9.org/showthread.php?p=1283664#post1283664
_By using a libavcodec or CoreAVC that isn't a year old.

[Sharktooth]

how can be properly decoded the new x264 lossless mode?

the problem is described here:

http://forum.doom9.org/showthread.php?p=1283664#post1283664
_
you already got your answer in the other thread.

[Clumpco]

Build 1153 crashing on decoder start under MeGui.
"Null exception"

[Trahald]

Megui is using an experimental patched 1153 which is causing the issue. use techhouses version for now

[Clumpco]

Megui is using an experimental patched 1153 which is causing the issue. use techhouses version for now

Ta mate! Rolled back to Skystrife 1148 and it worked fine again

[LoRd_MuldeR]

It appears that x264 r1157 crashes when using the ESA me-method:

$ gdb --args x264 --crf 22 --output c:\out.mkv --progress --me esa ../soccer.avs
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-mingw32"...
(gdb) run
Starting program: c:\temp\x264\vanilla/x264.exe --crf 22 --output c:out.mkv --progress --me esa ../soccer.avs
[New thread 4712.0x13f8]
[...] // Skipping Avisynth debug messages
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile Main, level 3.0
[0.3%] 1/299 frames, 16.13 fps, 19572.20 kb/s, eta 0:00:18
Program received signal SIGSEGV, Segmentation fault.
0x00457287 in x264_pixel_ads4_ssse3 ()
(gdb) bt
#0 0x00457287 in x264_pixel_ads4_ssse3 ()
#1 0x0279de52 in ?? ()
#2 0x00030000 in ?? ()
#3 0x50000161 in ?? ()
#4 0x7d62bc35 in wcstoui64 () from C:\WINDOWS\SysWOW64\ntdll32.dll
#5 0x00000000 in ?? ()
(gdb)

This is with an unpatched debug build, using MinGW GCC 4.4.0. No crash when using "--me umh" instead.

[Dark Shikari]

Fixed in r1158.

[LoRd_MuldeR]

Fixed in r1158.

:thanks:

[simps]

I couldn't find the answer for this question, searching doom9.

Talking about 2passes encode here.

On old versions of x264, when a --vbv-maxrate was specified, but no --vbv-bufsize (leaving it at default "0" value), the encoder used to pop a warning like this:

"x264 [warning]: VBV maxrate specified, but no bufsize."

I was testing the current version, and when I enter a --vbv-maxrate, without any --vbv-bufsize, the encoder will proceed without any warnings.

Does this mean, x264 is now just ignoring --vbv-maxrate when no --vbv-bufsize is set and not showing any warning anymore, or is --vbv-maxrate actually working the right way without any --vbv-bufsize set? Or something different is happening?

Thanks,
Simps

[Dark Shikari]

I couldn't find the answer for this searching doom9.

Talking about 2passes encode here.

On old versions of x264, when a --vbv-maxrate was specified, but no --vbv-bufsize (leaving it at default "0" value), the encoder used to pop a warning like this:

"x264 [warning]: VBV maxrate specified, but no bufsize."

I was testing the current version, and when I enter a --vbv-maxrate, without any --vbv-bufsize, the encoder will proceed without any warnings.

Does this mean, x264 is now just ignoring --vbv-maxrate when no --vbv-bufsize is set, or is --vbv-maxrate actually working the right way without any --vbv-bufsize? Or something different is happening?

Thanks,
Simps if( h->param.rc.i_vbv_max_bitrate < h->param.rc.i_bitrate &&
h->param.rc.i_vbv_max_bitrate > 0)
x264_log(h, X264_LOG_WARNING, "max bitrate less than average bitrate, ignored.\n");
else if( h->param.rc.i_vbv_max_bitrate > 0 &&
h->param.rc.i_vbv_buffer_size > 0 )
{
if( h->param.rc.i_vbv_buffer_size < 3 * h->param.rc.i_vbv_max_bitrate / rc->fps )
{
h->param.rc.i_vbv_buffer_size = 3 * h->param.rc.i_vbv_max_bitrate / rc->fps;
x264_log( h, X264_LOG_WARNING, "VBV buffer size too small, using %d kbit\n",
h->param.rc.i_vbv_buffer_size );
}

...

}
else if( h->param.rc.i_vbv_max_bitrate )
{
x264_log(h, X264_LOG_WARNING, "VBV maxrate specified, but no bufsize.\n");
h->param.rc.i_vbv_max_bitrate = 0;
}

[simps]

DS, I am still confused. I set --bitrate 240 --vbv-maxrate 1200 and --vbv-bufsize 0 (I just left it default), and x264 proceded without warning.



From the code you posted:



1st part (not my case, I don't have --vbv-maxrate < --bitrate)

if( h->param.rc.i_vbv_max_bitrate < h->param.rc.i_bitrate &&
h->param.rc.i_vbv_max_bitrate > 0)
x264_log(h, X264_LOG_WARNING, "max bitrate less than average bitrate, ignored.\n");



2nd part (not my case, I don't have --vbv-bufsize > 0)

else if( h->param.rc.i_vbv_max_bitrate > 0 &&
h->param.rc.i_vbv_buffer_size > 0 )
{
if( h->param.rc.i_vbv_buffer_size < 3 * h->param.rc.i_vbv_max_bitrate / rc->fps )
{
h->param.rc.i_vbv_buffer_size = 3 * h->param.rc.i_vbv_max_bitrate / rc->fps;
x264_log( h, X264_LOG_WARNING, "VBV buffer size too small, using %d kbit\n",
h->param.rc.i_vbv_buffer_size );
}



3rd part (This should be my case, but why I don't see any warnings? If there is no warning, how do I know that routine is going on, and setting -vbv-maxrate to 0 in this case???)


else if( h->param.rc.i_vbv_max_bitrate )
{
x264_log(h, X264_LOG_WARNING, "VBV maxrate specified, but no bufsize.\n");
h->param.rc.i_vbv_max_bitrate = 0; }




I got no warning:
http://img33.imageshack.us/img33/515/vbv.jpg

Thanks,
Simps

[Dark Shikari]

DS, I am still confused. I set --bitrate 240 --vbv-maxrate 1500 and --vbv-bufsize 0 (I just left it default), and x264 proceded without warning.Bug introduced by aku's level autodetection code. Fix will be incoming soon. Thanks for the report.

[simps]

Bug introduced by aku's level autodetection code. Fix will be incoming soon. Thanks for the report.

No problem, btw, it is probably setting --vbv-maxrate to 0 or ignoring it, just not showing the warning.
I set --vbv-maxrate 1200, but I got up to 1700kb/s peak as per pic below:

http://img194.imageshack.us/img194/8930/vbv2.jpg

[b66pak]

i encoded a movie using "x264 core 67 r1159 3da3f95":


General
Complete name : movie.mp4
Format : MPEG-4
Format profile : Base Media
Codec ID : isom
File size : 3.98 GiB
Duration : 2h 9mn
Overall bit rate : 4 404 Kbps
Encoded date : UTC 2009-05-25 06:54:24
Tagged date : UTC 2009-05-25 06:54:24

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 3 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 2h 9mn
Bit rate mode : Variable
Bit rate : 4 211 Kbps
Maximum bit rate : 11.2 Mbps
Width : 1 280 pixels
Height : 532 pixels
Display aspect ratio : 2.406
Frame rate mode : Constant
Frame rate : 23.976 fps
Resolution : 24 bits
Colorimetry : 4:2:0
Scan type : Progressive
Bits/(Pixel*Frame) : 0.258
Stream size : 3.80 GiB (96%)
Writing library : x264 core 67 r1159 3da3f95
Encoding settings : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=5 / psy_rd=0.0:0.0 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=0 / 8x8dct=1 / cqm=0 / deadzone=21,11 / chroma_qp_offset=0 / threads=1 / nr=0 / decimate=1 / mbaff=0 / bframes=3 / b_pyramid=0 / b_adapt=2 / b_bias=0 / direct=3 / wpredb=1 / keyint=24 / keyint_min=1 / scenecut=40 / rc=2pass / bitrate=4211 / ratetol=1.0 / qcomp=0.50 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=30000 / vbv_bufsize=30000 / ip_ratio=1.10 / pb_ratio=1.10 / aq=1:1.00
Encoded date : UTC 2009-05-25 06:54:24
Tagged date : UTC 2009-05-25 06:59:53

Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format version : Version 4
Format profile : LC
Format settings, SBR : No
Codec ID : 40
Duration : 2h 9mn
Bit rate mode : Variable
Bit rate : 192 Kbps
Maximum bit rate : 233 Kbps
Channel(s) : 2 channels
Channel positions : L R
Sampling rate : 48.0 KHz
Resolution : 16 bits
Stream size : 175 MiB (4%)
Encoded date : UTC 2009-05-25 06:59:41
Tagged date : UTC 2009-05-25 06:59:53


here is the log:


[Information] Log
-[Information] Versions
--[NoImage] MeGUI Version : 0.3.1.1037
--[NoImage] OS : Windows XP Professional x86 SP3 (5.1.196608.2600)
--[NoImage] Framework used : 2.0 SP1 (2.0.50727.1433)
-[Information] Hardware
--[NoImage] CPU : AMD Athlon(tm) 64 Processor 3800+
-[Information] Log for job1 (video, movie.avs -> )
--[Information] [5/25/2009 9:09:14 PM] Started handling job
--[Information] [5/25/2009 9:09:14 PM] Preprocessing
---[Information] Bitrate calculation for video
----[NoImage] Desired size after subtracting audio: 3987101KBs
----[NoImage] Calculated desired bitrate: 4211kbit/s
--[NoImage] Job commandline: "C:\Program Files\megui\tools\x264\x264.exe" --pass 1 --bitrate 4211 --stats "movie.stats" --level 4.1 --keyint 24 --min-keyint 1 --bframes 3 --b-adapt 2 --weightb --direct auto --subme 2 --partitions none --ipratio 1.1 --pbratio 1.1 --vbv-bufsize 30000 --vbv-maxrate 30000 --qcomp 0.5 --me dia --threads auto --thread-input --sar 1:1 --progress --no-psnr --no-ssim --output NUL "movie.avs"
--[Information] [5/25/2009 9:09:19 PM] Encoding started
--[NoImage] Standard output stream
--[NoImage] Standard error stream
---[NoImage] avis [info]: 1280x532 @ 23.98 fps (185957 frames)
---[NoImage] x264 [warning]: width or height not divisible by 16 (1280x532), compression will suffer.
---[NoImage] x264 [info]: using SAR=1/1
---[NoImage] x264 [info]: using cpu capabilities: MMX2 SSE2Slow
---[NoImage] x264 [info]: profile Main, level 4.1
---[NoImage]
---[NoImage] x264 [info]: slice I:14188 Avg QP:19.24 size: 49411
---[NoImage] x264 [info]: slice P:81071 Avg QP:18.35 size: 27061
---[NoImage] x264 [info]: slice B:90698 Avg QP:19.37 size: 12875
---[NoImage] x264 [info]: consecutive B-frames: 12.4% 39.4% 36.3% 11.9%
---[NoImage] x264 [info]: mb I I16..4: 39.6% 0.0% 60.4%
---[NoImage] x264 [info]: mb P I16..4: 34.9% 0.0% 0.0% P16..4: 58.0% 0.0% 0.0% 0.0% 0.0% skip: 7.1%
---[NoImage] x264 [info]: mb B I16..4: 11.8% 0.0% 0.0% B16..8: 31.7% 0.0% 0.0% direct:22.6% skip:33.9% L0:31.7% L1:45.5% BI:22.8%
---[NoImage] x264 [info]: final ratefactor: 19.71
---[NoImage] x264 [info]: direct mvs spatial:99.7% temporal:0.3%
---[NoImage] x264 [info]: coded y,uvDC,uvAC intra:79.3% 64.2% 29.7% inter:33.2% 31.6% 1.8%
---[NoImage] x264 [info]: kb/s:4190.4
---[NoImage] encoded 185957 frames, 10.14 fps, 4190.94 kb/s
--[Information] [5/26/2009 2:14:50 AM] Postprocessing
--[Information] [5/26/2009 2:14:50 AM] Job completed
-[Information] Log for job2 (video, movie.avs -> movie.264)
--[Information] [5/26/2009 2:14:50 AM] Started handling job
--[Information] [5/26/2009 2:14:50 AM] Preprocessing
--[NoImage] Job commandline: "C:\Program Files\megui\tools\x264\x264.exe" --pass 2 --bitrate 4211 --stats "movie.stats" --level 4.1 --keyint 24 --min-keyint 1 --ref 3 --mixed-refs --no-fast-pskip --bframes 3 --b-adapt 2 --weightb --direct auto --subme 5 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --ipratio 1.1 --pbratio 1.1 --vbv-bufsize 30000 --vbv-maxrate 30000 --qcomp 0.5 --threads auto --thread-input --sar 1:1 --aud --progress --no-psnr --no-ssim --output "movie.264" "movie.avs"
--[Information] [5/26/2009 2:14:51 AM] Encoding started
--[NoImage] Standard output stream
--[NoImage] Standard error stream
---[NoImage] avis [info]: 1280x532 @ 23.98 fps (185957 frames)
---[NoImage] x264 [warning]: width or height not divisible by 16 (1280x532), compression will suffer.
---[NoImage] x264 [info]: using SAR=1/1
---[NoImage] x264 [info]: using cpu capabilities: MMX2 SSE2Slow
---[NoImage] x264 [info]: profile High, level 4.1
---[NoImage]
---[NoImage] x264 [info]: slice I:14188 Avg QP:18.98 size: 49148
---[NoImage] x264 [info]: slice P:81071 Avg QP:18.11 size: 26511
---[NoImage] x264 [info]: slice B:90698 Avg QP:18.80 size: 13627
---[NoImage] x264 [info]: consecutive B-frames: 12.4% 39.4% 36.3% 11.9%
---[NoImage] x264 [info]: mb I I16..4: 14.6% 54.5% 31.0%
---[NoImage] x264 [info]: mb P I16..4: 8.8% 24.9% 6.4% P16..4: 31.8% 17.6% 5.3% 0.0% 0.0% skip: 5.2%
---[NoImage] x264 [info]: mb B I16..4: 10.4% 0.0% 0.0% B16..8: 32.1% 4.0% 2.9% direct:16.4% skip:34.1% L0:39.4% L1:42.7% BI:17.9%
---[NoImage] x264 [info]: 8x8 transform intra:49.7% inter:39.8%
---[NoImage] x264 [info]: direct mvs spatial:95.7% temporal:4.3%
---[NoImage] x264 [info]: coded y,uvDC,uvAC intra:83.5% 67.4% 30.4% inter:29.4% 27.8% 1.3%
---[NoImage] x264 [info]: ref P L0 78.5% 14.2% 7.3%
---[NoImage] x264 [info]: ref B L0 83.0% 17.0%
---[NoImage] x264 [info]: kb/s:4211.0
---[NoImage] encoded 185957 frames, 6.75 fps, 4212.74 kb/s
--[Information] Final statistics
---[NoImage] Video Bitrate Desired: 4211 kbit/s
---[NoImage] Video Bitrate Obtained (approximate): 4212 kbit/s
--[Information] [5/26/2009 9:54:22 AM] Postprocessing
--[Information] [5/26/2009 9:54:22 AM] Job completed
-[Information] Log for job3 (mux, movie.264 -> movie-muxed.mp4)
--[Information] [5/26/2009 9:54:22 AM] Started handling job
--[Information] [5/26/2009 9:54:22 AM] Preprocessing
--[NoImage] Job commandline: "C:\Program Files\megui\tools\mp4box\mp4box.exe" -add "movie.264:fps=23.976" -add "audio.m4a#trackID=1" -tmp "F:\Movie" -new "movie.mp4"
--[Information] [5/26/2009 9:54:23 AM] Encoding started
--[NoImage] Standard output stream
---[NoImage] AVC-H264 import - frame size 1280 x 532 at 23.976 FPS
---[NoImage] Import results: 185957 samples - Slices: 14188 I 81071 P 90698 B - 1 SEI - 14188 IDR
---[NoImage] IsoMedia import - track ID 1 - Audio (SR 48000 - 2 channels)
---[NoImage] Saving movie-muxed.mp4: 0.500 secs Interleaving
--[NoImage] Standard error stream
--[Information] [5/26/2009 10:04:34 AM] Postprocessing
--[Information] [5/26/2009 10:04:34 AM] Job completed
-[Information] [5/26/2009 10:05:07 AM] Shutdown initiated


since now i never noticed that the I frames have lover QP that P frames...is this normal?
_

[Audionut]

since now i never noticed that the I frames have lover QP that P frames...is this normal?
_

ip_ratio=1.10 / pb_ratio=1.10

It is with those silly settings. Use defaults

ip_ratio=1.40 / pb_ratio=1.30

[juGGaKNot]

It is with those silly settings. Use defaults

ip_ratio=1.40 / pb_ratio=1.30

1.1 is ps3/xbox profile default in megui.

[Audionut]

megui often uses stupid settings in it's profiles.

[plato79]

will there be any OpenCL support in the future?

[J_Darnley]

"Patches welcome"

[Fr4nz]

will there be any OpenCL support in the future?

Very very unlikely: it would require a LOT of work. On top of all, from what I understand, it would require a complete redesign of the approach, regarding mainly the parallelization, in writing various algorithms which x264 currently uses.

[Sharktooth]

megui often uses stupid settings in it's profiles.
that choice was already been discussed. and FYI it's normal I frames have lower QP than other frames... even more at default settings. so please dont make silly comments.

[Audionut]

and FYI it's normal I frames have lower QP than other frames.

Yes!! But read more closely and you'll see,

---[NoImage] x264 [info]: slice I:14188 Avg QP:19.24 size: 49411
---[NoImage] x264 [info]: slice P:81071 Avg QP:18.35 size: 27061


Caused by stupid ip/pb ratio settings.

so please dont make silly comments.

Thanks, but open your eyes.