x264 cli bugreports

[Sharktooth]

that's not a bug but an intended behaviour.
talking about compression efficiency and CRF doesnt have much sense.
fact is, at the same filesize, the new x264 version gives better quality. hence, use the newer version and rise the CRF until you get your desirer filesize (and as i said, at the same filesize, you'll get a better quality).

[garbii]

that's not a bug but an intended behaviour.
talking about compression efficiency and CRF doesnt have much sense.
fact is, at the same filesize, the new x264 version gives better quality. hence, use the newer version and rise the CRF until you get your desirer filesize (and as i said, at the same filesize, you'll get a better quality).
I played with different numbers of CRF and the problem here is the differences in size. As you can see with new x264 the GUndam episode is quite close in size to what the old one was... The quality is also good. However less action packed shows like Munto and Minami are a lot larger then the old ones while having the same quality. THis is what I consider a bug because I found my desired quality (crf=22), but it doesn't seem to work as the old one did for non action shows.

[nm]

Old crf=20
minami-ke 08 size 42 MB
gundam 00 s2 20 size 80 MB

new crf=22
minami-ke 08 size 56 MB
gundam 00 s2 20 size 84 MB

Munto 05
old = 54 mb
new=70 mb

Now the difference on the same files shows that new crf mode is less efficient then the old one... So I consider this a bug since new version provides the same quality but with a lot larger files .
It would be better to do a 2-pass encode to the same size and then compare quality visually.

Looks like your source is anime. The 2008-04 version of x264 didn't have psy-RD, which may not be a good idea for animation. Now psy-RD is enabled by default, so try disabling it with --psy-rd 0.0:0.0 (or psy-rd=0.0,0.0 if you use MEncoder).

[Sharktooth]

I played with different numbers of CRF and the problem here is the differences in size. As you can see with new x264 the GUndam episode is quite close in size to what the old one was... The quality is also good. However less action packed shows like Munto and Minami are a lot larger then the old ones while having the same quality. THis is what I consider a bug because I found my desired quality (crf=22), but it doesn't seem to work as the old one did for non action shows.
again, this is not a bug but an intended behaviour.
as nm said, try disabling psy options since your encode is anime.

[garbii]

I enabled psy-rd=0.0,0.0 and gave new build a try I still have the same problem though... Let me rephrase. CRF should be a stable quality factor so once I choose the crf value I like it should always give me the same quality on files, or similiar at least. This is not the case with new crf, where I should consider the source and then choose the crf and if I have to do that I might as well use good old 2pass bitrate.

Extreme example of non action source vs a very demanding fast paced source:

Old crf=20
gundam 00 s2 ep 23 140 MB
mianami-ke okaeri 10 43 MB
both encodes have similiar quality. Both files are a 20 minutes shows.

New crf=24
gundam 00 s2 ep 23 81 MB
mianami-ke okaeri 10 45 MB
While the non action minami has good quality the 80 mb gundam encode just sucks in terms of quality.


New crf=22
gundam 00 s2 ep 23 100 MB
mianami-ke okaeri 10 53 MB
Quality wise minami seems the same as crf=24, it size is larger though ... Gundam is better then the previous encode but still not as good as the 140 MB encode which is just natural :)

I find it that new crf behavour makes this mode uselles for me. This example should really show that the previous version was better at keeping the same quality and not over enlarging filesize where not needed . With the old mode I could just set it to one value and not worry because all my encodes ended with similiar quality, with the new mode I would have to use 21 or maybe 20 for gundam and 24 for minami ... Now for me that's not what constant quality mode should be all about.

[Dark Shikari]

I enabled psy-rd=0.0,0.0 and give new build a try I still have the same problem though... Let me rephrase. CRF should be a stable quality factor so once I choose the crf value I like it should always give me the same quality on files, or similiar at least. This is not the case with new crf, where I should consider the source and then choose the crf and if I have to do that I might as well use good old 2pass bitrate.

Extreme example of non action source vs a very demanding fast paced source:

Old crf=20
gundam 00 s2 ep 23 140 MB
mianami-ke okaeri 10 43 MB
both encodes have similiar quality.

New crf=24
gundam 00 s2 ep 23 81 MB
mianami-ke okaeri 10 45 MB
While the non action minami has good quality the 80 mb gundam encode just sucks in terms of quality.


New crf=22
gundam 00 s2 ep 23 100 MB
mianami-ke okaeri 10 53 MB
Quality wise minami seems the same as crf=24, it size is larger though ... Gundam is better then the previous encode but still not as good as the 140 MB encode which is just natural :)

I find it that new crf behavour makes this mode uselles for me. This example should really show that the previous version was better at keeping the same quality and not over enlarging filesize where not needed . With the old mode I could just set it to one value and not worry because all my encodes ended with similiar quality, with the new mode I would have to use 22 or maybe 20 for gundam and 24 for minami ... Now for me that's not what quality mode should be all about.I had exactly the same problem with the old CRF--which was fixed with my modifications. My Touhou clips could reach CRF ~30-35 without noticeable degradation while BlackPearl looked crap at above ~24. So, to paraphrase you, "the old CRF is useless to me."

Unless you can come up with a magical algorithm for judging the human visual system, there is no guarantee that any CRF algorithm will give equivalent quality across all sources--in fact, it's almost guaranteed it will not.

Anyways, the proper approach here is not to blame CRF but to adjust qcomp until you are satisfied with the mapping between CRF and quality level.

Also, though you probably don't realize this, there have actually been three CRFs.

1. Original CRF (similar to current CRF)

2. CRF after AQ (qcomp completely disabled)

3. New CRF (most similar to original CRF)

Let me put this in a nice large font size here:
During 2), CRF was effectively broken. The "new" CRF merely restored the original behavior.

If you don't like this behavior, what you really want is qcomp=1, i.e. disabled.

[audyovydeo]

Also, though you probably don't realize this, there have actually been three CRFs.

1. Original CRF (similar to current CRF)

2. CRF after AQ (qcomp completely disabled)

3. New CRF (most similar to original CRF)



mmmh, interesting. I assume that :

1 = <r968
2 = r968
3 = >r????


cheers
audyovydeo

[nm]

mmmh, interesting. I assume that :

1 = <r968
2 = r968
3 = >r????
I'd guess something like this:

1: rev < r804 (variance-based psy adaptive quantization)
2: r804 <= rev < r968
3: rev >= r968 (move adaptive quantization to before ratecontrol, eliminate qcomp bias)

[garbii]

If you don't like this behavior, what you really want is qcomp=1, i.e. disabled.

Thanks that helped :) However just so you know it still not the same as the old "broken" crf. While it gives the same filesizes (and better quality) it's only up to some point . For example the eariler mentioned gundam ep with crf=22 and qcomp=1 ended up as a 102 MB file while with old value it was 140 mb ...

The quality of the mentioned ep is still quite good (not as good as the 140 mb one obviously) and I'm aiming to end up with small files anyway so I'm happy :)

Thank you for your help, and I still don't like how the normal non "broken" crf behaves ... oh well ...

[daimroc]

I get the error malloc size with de x264 r1201 (32 bits).

I have the following command line:

x264 --crf 16 --keyint 240 --min-keyint 24 --scenecut 40 --bframes 16 --b-adapt 2 --ref 4 --deblock 0:0 --qpmin 5 --qpmax 24 --aq-mode 1 --aq-strength 0.25 --mbtree --partitions all --direct auto --weightb --me tesa --merange 32 --mvrange -1 --mvrange-thread -1 --subme 9 --psy-rd 1.0:0.0 --mixed-refs --8x8dct --trellis 2 --no-fast-pskip --no-dct-decimate --nr 0 --threads auto --thread-input --output "video.mkv" "video.avs"



My avs is:

DirectShowSuorce("video.,m2ts")
Crop(Crop(0,132,-0,-132)

The source is a 1080p video, which I do a crop.

If I do a resize to 640x368 for example I don't have any problem.

I have a Core 2 Duo E6750 with 2GB of RAM, winth windows vista x64.




Thanks.
Daimroc.

[Dark Shikari]

That means your computer ran out of mappable memory for x264. Upgrade to 64-bit or stop using such insane settings.

[nm]

My avs is:

DirectShowSuorce("video.,m2ts")
Crop(Crop(0,132,-0,-132)
Try limiting AviSynth memory usage by adding SetMemorymax(32) to the script.

[VFR maniac]

Rev1201 mp4 output is broken, because the error is returned in write_nalu_mp4 though malloc has succeeded.

Here (http://www.esnips.com/doc/29a52597-d923-4ac0-96be-8e5b7ce14dff/x264_fix_mp4output_broken) is patch.

[CruNcher]

1201 crashes here :(

ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
Transcoding Video: parkrun.avs / FPS: 25.000
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ

avis [info]: 1280x720 @ 25.00 fps (489 frames)
x264 [info]: using cpu capabilities: MMX2 SSE2Slow
x264 [info]: profile High, level 3.1
mp4 [info]: initial delay 1 (scale 25)
[8.6%] 42/489 frames, 31.25 fps, 0.00 kb/s, eta 0:00:14


very simple params
x264.exe "%SourceVideo%" --crf 29 -o "%SourceVideo%.mp4"

yep happens only with .mp4 as output container

[kemuri-_9]

mp4 output should be working again in r1202, sorry for the 10L.

[bob0r]

mp4 output should be working again in r1202, sorry for the 10L.

10 Litres of Coke – Not Good Idea (http://a-h-z.com/cola-in-excess-can-paralyse/)

[bitbytebit]

Not sure if this is a bug or a major change in behavior, guessing it's some kind of memory leak though.

I have a program using x264 using the avcodec API, opens and closes the x264 encoder from there making 2 minute segments of video. Up to this version "x264 core:68 r1195 5d75a9b" memory usage stays at the same amount over 24 hours of opening/closing x264 (see in the ffmpeg libx264.c how it uses the open/close stuff to x264). When I try using the newer one (Macroblock-tree ratecontrol) and beyond with mbtree and rc_lookahead both on/off, then memory usage just climbs each close/open in ffmpeg avcodec of x264. This happens really fast with mbtree on, 4-5 meg per segmentation point, while even with both settings set to 0 (have altered ffmpeg libx264.c to use mbtree) it just does it slower and more like 1 meg per encoding. After a few hours this gets bad, while running the program with the older x264 it runs all day. Also can run the same program with any other codec from avcodec and doesn't budge in memory usage, just newer x264 using versions past the mbtree addition.

Not sure if it's ffmpeg using it wrong and some change caught that, have double checked and code seems like x264.c besides how they alloc the x4->pic structure. Seems like something may be the culprit in the mbtree stuff though, which looks awesome by the way and great for my encoding method (being very low bitrate), yet trying to get around this memory problem that occurs now. It works great on one shot programs, just when opened/closed multiple times seems to eat up memory till program exit.

Also using the newest git from just now, r1202, doesn't change the behavior I'm seeing (so seems to in the mbtree changes). Thanks for the hard work, mbtree is definitely an exciting feature.

[Chengbin]

mbtree EATS RAM. It is not a bug.

[Dark Shikari]

Not sure if this is a bug or a major change in behavior, guessing it's some kind of memory leak though.

I have a program using x264 using the avcodec API, opens and closes the x264 encoder from there making 2 minute segments of video. Up to this version "x264 core:68 r1195 5d75a9b" memory usage stays at the same amount over 24 hours of opening/closing x264 (see in the ffmpeg libx264.c how it uses the open/close stuff to x264). When I try using the newer one (Macroblock-tree ratecontrol) and beyond with mbtree and rc_lookahead both on/off, then memory usage just climbs each close/open in ffmpeg avcodec of x264. This happens really fast with mbtree on, 4-5 meg per segmentation point, while even with both settings set to 0 (have altered ffmpeg libx264.c to use mbtree) it just does it slower and more like 1 meg per encoding. After a few hours this gets bad, while running the program with the older x264 it runs all day. Also can run the same program with any other codec from avcodec and doesn't budge in memory usage, just newer x264 using versions past the mbtree addition.

Not sure if it's ffmpeg using it wrong and some change caught that, have double checked and code seems like x264.c besides how they alloc the x4->pic structure. Seems like something may be the culprit in the mbtree stuff though, which looks awesome by the way and great for my encoding method (being very low bitrate), yet trying to get around this memory problem that occurs now. It works great on one shot programs, just when opened/closed multiple times seems to eat up memory till program exit.

Also using the newest git from just now, r1202, doesn't change the behavior I'm seeing (so seems to in the mbtree changes). Thanks for the hard work, mbtree is definitely an exciting feature.Can you replicate the leak with Valgrind?

[bitbytebit]

Chengbin: It's with mbtree on or off actually.

Dark Shikari: I've tried, but it seems to not report any problems, not sure if I'm using it right....

valgrind -v --tool=memcheck --leak-check=yes --leak-resolution=high --show-reachable=yes --undef-value-errors=no PROGRAM

It always says everything was freed when I terminate the program, and exit really does the exact same stuff that each segmentation does...

/* free the streams */
for(i = 0; i < cs->oc->nb_streams; i++) {
avcodec_close(cs->oc->streams[i]->codec);
av_free(cs->oc->streams[i]->codec);
av_free(cs->oc->streams[i]);
}

// Free Muxer and Output Codecs
av_free(cs->oc);
cs->oc = NULL;
cs->vEncCtx = NULL;
cs->vEncCodec = NULL;
cs->video_st = NULL;
cs->audio_st = NULL;


So all that seems like it should free that x264 encoding instance, not sure what else would be hanging around still after all that.

[Dark Shikari]

Have you tried using libx264 directly instead of through libavcodec?

[bitbytebit]

That's actually my next idea I want to try, what I originally had ideally wanted but of course using libavcodec was easier and added muxing + easy video functions prewrapped. Doesn't look too daunting and would be nice to directly work with it, hoping that could fix it (although also worried it'll just be the same, since just changing x264 versions makes the libavcodec get the bad behavior, although it'd still be worth it either way getting x264 API usage direct in my program.).

[Dark Shikari]

Also, note that Valgrind should report at least one leak: x264 intentionally "leaks" a constant amount of statically allocated memory which is shared across all x264 processes and isn't re-allocated when you call x264 again (so it's not a leak over time); this is the few megabytes used for the MV cost arrays. If valgrind works correctly, it should whine about these, generally.

[bitbytebit]

Strange, it's not saying anything wrong for me, valgrind seems too happy then (in both newer/older x264 library)...

==8565==
==8565== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==8565== malloc/free: in use at exit: 0 bytes in 0 blocks.
==8565== malloc/free: 0 allocs, 0 frees, 0 bytes allocated.
==8565== For counts of detected errors, rerun with: -v
==8565== All heap blocks were freed -- no leaks are possible.


Not sure how outputs happening then, seems like it should see the intentional leak, unless it's not able to see beyond avcodec (although isn't it supposed to see everything, I've got it all compiled with debugging too).

[bitbytebit]

Figured out the valgrind problem, now it's reporting things. The first is the previous x264 before mbtree and the second result is after (have the full output, with full debug on so shows files+line numbers, let me know if you want that and how to get it to you)....

x264 before mbtree:

==9092== LEAK SUMMARY:
==9092== definitely lost: 764 bytes in 30 blocks.
==9092== indirectly lost: 1,632 bytes in 78 blocks.
==9092== possibly lost: 1,644,994 bytes in 38 blocks.
==9092== still reachable: 11,114,785 bytes in 797 blocks.
==9092== suppressed: 0 bytes in 0 blocks.

Current GIT x264:
==9362== LEAK SUMMARY:
==9362== definitely lost: 4,671,872 bytes in 10,297 blocks.
==9362== indirectly lost: 2,630,324 bytes in 3,669 blocks.
==9362== possibly lost: 7,377,089 bytes in 291 blocks.
==9362== still reachable: 2,957,742 bytes in 604 blocks.
==9362== suppressed: 0 bytes in 0 blocks.


This is from running my program in 10 loops of segmentation (1 second ones so it didn't take all day being slow under valgrind).

[Dark Shikari]

Figured out the valgrind problem, now it's reporting things. The first is the previous x264 before mbtree and the second result is after (have the full output, with full debug on so shows files+line numbers, let me know if you want that and how to get it to you)....pastebin.

[bitbytebit]

Here's the output.... http://pastebin.com/m13806d41

Here's the exact info of what options setup in x264.... http://pastebin.com/m1d5b5a12

[Dark Shikari]

Fixed.

[bitbytebit]

Great, my program is no longer eating more and more memory over time, thanks for the quick fixing of this.

[daimroc]

I tried to use the command SetMemorymax(32) in the avs script but it doesn.t solve the problem.

I try to use the 64 bits versión of the x264, but I have problems with the avs2yuv. Although I always use this settings and I don't have any problem with r1195 of the 32 bits version of x264. I only have this problems with this new builds.

I use the same avs, and the command line is:

avs2yuv -raw "video.avs" - | "x264.exe" --crf 16 --keyint 240 --min-keyint 24 --scenecut 40 --bframes 16 --b-adapt 2 --ref 4 --deblock 0:0 --qpmin 5 --qpmax 24 --aq-mode 1 --aq-strength 0.25 --mbtree --partitions all --direct auto --weightb --me tesa --merange 32 --mvrange -1 --mvrange-thread -1 --subme 9 --psy-rd 1.0:0.0 --mixed-refs --8x8dct --trellis 2 --no-fast-pskip --no-dct-decimate --nr 0 --threads auto --output "video.mkv" - 1920x816

But I get the following error:

Video returned: "DirectShowSource: Renderfile, the filter graph manager won't talk to me".

What I do wrong?




Thanks.
Daimroc.

[thewebchat]

My guess is that the error has nothing to do with x264 but rather to do with this:


DirectShowSuorce("video.,m2ts")
Crop(Crop(0,132,-0,-132)

[daimroc]

Well, in the first post I made a mistake with the copy paste.

I have the following lines in the AVS:

DirectShowSource("00000.m2ts", audio=false)
Crop(0,132,-0,-132)



Thanks.
Daimroc.

[OvejaNegra]

the whole story:

my neighbour has the whole collection of 007 movies (all of them, except q of solace, but that one is on the way).


he ask me if i can do the conversion to mkv with the usuall stuff, i say yes because that way i can watch all the
007 movies (therea are a lot of them)

one of the DVDs started to show a lot of small white spots (maybe fungus) 2 or 3 years ago, so he made a recompressed
backup of the whole DVD with all the extras and audio tracks, so quality is totally destroyed on that one (goldfinger)


i'm trying to save it with this script (the second pass of two passes for tivtc):


DGDecode_mpeg2source("dgp.d2v", info=3,cpu=6)

ColorMatrix(hints=true, interlaced=true, threads=0)


interp = separatefields().EEDI2(field=-2)
px = tdeint(type=2,edeint=interp,mode=2,full=true)


#matching paso2
TFM (order=-1,mode=0,pp=5,display=false,clip2=px,slow=2,cthresh=9,d2v="dgp.d2v",input="TFM_matches.txt",ovr="ovr.txt",batch=true)


#decimating paso2
TDecimate (mode=5,hybrid=2,display=false,batch=true,input="TD_metrics.txt",tfmIn="TFM_matches.txt",mkvOut="tiempos.txt")

crop(8,0,704,480)



#from GK
Temporalsoften(3,5,5,mode=2,scenechange=10)
Convolution3d("moviehq")
FluxSmoothST(7,7)

#end


now this is what i'm using for all the collection without problems (of course with different filters)

this time, is the first time i'm using deblocking with DGDECODE

when i start the compression, on the first pass, x264 crash at 40% approx.


same hardware, no recent changes on eviroment (new software or anything like that).

i ran a analisys pass with megui without problems (the full movie) and my last attempt was direct with the cli encoder
(no megui)


now:
WXP SP3 32bits
DualCore Intel Pentium E2160, 1800 MHz (9 x 200)
MB Intel Coconut Creek D945GCCR (2 PCI, 1 PCI-E x1, 1 PCI-E x16, 2 DDR2 DIMM, Audio, Video, LAN)
Chipset Intel Lakeport-G i945GC
DIMM1: Kingston 9905316-005.A04LF 1 GB DDR2-667 DDR2 SDRAM (5-5-5-15 @ 333 MHz) (4-4-4-12 @ 266 MHz) (3-3-3-9 @ 200 MHz)

X264 cli output:

x264.exe --profile high --pass 1 --bitr
ate 1653 --stats ".stats" --ref 1 --no-mixed-refs --bframes 2 --b-adapt 2 --dire
ct auto --subme 2 --trellis 0 --partitions none --qpmin 12 --vbv-init 1.0 --me d
ia --thread-input --output NUL "e:\007\video proc\p2.avs"
avis [info]: 704x480 @ 23.98 fps (158257 frames)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile Main, level 3.0
[56.3%] 89050/158257 frames, 4.47 fps, 1652.03 kb/s, eta 4:18:13
"../kmp_runtime.c", line 5235: OMP runtime internal error: assertion failure.

Please submit a bug report with this message, compile and run commands used,
and machine configuration info including native compiler and operating system
versions. Faster response will be obtained by including all program sources.
Please send submissions to http://premier.intel.com/

PD you can see the low fps? well is not true, the frame counter runs faster than that

x264 core:70 r1203 6f4054f (but using the build i had before does not fix the problem)

i continue using my pc without problems, gaming, watching videos, music, everything seems ok, no perfomance loss or crashes on my aplications

if anybody needs more info like the stats, just ask
im using the last version for all my AVS filters and AVS 258

thanks

[OvejaNegra]

i just disabled macroblock tree ratecontrol.

everything is just fine now

[ChaosKing]

I've just ran some test encodes and then got this error: malloc of size 3211264 failed/s
And it seems that x264 dont like '%' in filenames.

x264 core:70 r1206 01a693d

start /b /w x264.exe --rc-lookahead 200 --preset placebo --crf 26 --keyint 240 --thread-input --output "ichi.mkv" "Ichigo.avs"
avis [info]: 960x720 @ 23.98 fps (1120 frames)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.1 Cache64
x264 [info]: profile High, level 5.0
x264 [error]: malloc of size 3211264 failed/s, eta 0:00:21
x264 [error]: x264_encoder_encode failed

[Underground78]

I think this answer probably applies to your malloc error :

That means your computer ran out of mappable memory for x264. Upgrade to 64-bit or stop using such insane settings.

[ChaosKing]

thx, 64bit works without problems

[juGGaKNot]

after using bframes 0 and going back to bframes 3 cli crashes at the last frame in the first pass, 4 times in a row

set useless=--level %mylevel% --bitrate %btratex264% --stats "%mypath%\%mpath%\T1\movie.stats" --keyint %kint% --min-keyint %mint% --fullrange on --ref %myrefs% --bframes 3 --ratetol 2.0 --merange 32 --direct temporal --aq-mode 2 --no-fast-pskip --no-dct-decimate --vbv-bufsize 20000 --vbv-maxrate 20000 --nal-hrd --sar 1:1 --aud
echo.
echo %useless%
echo.
start "encode" /b /low /wait "%mypath%\bin\x264.exe" --pass 1 --preset veryslow %useless% --slow-firstpass --output NUL %myavs%
echo.
echo %langi%
echo.
start "encode" /b /low /wait "%mypath%\bin\x264.exe" --pass 2 --preset veryslow %useless% --output "%mypath%\%mpath%\T1\%mymovie%.264" %myavs%

same settings worked before with bframes 3, worked with bframes 0 not that i went back to bframes 3 it crashes

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

i will edit with in 10 minutes with the cli log

[Dark Shikari]

GDB backtrace? Does it occur with YUV input?

[juGGaKNot]

avs

echo AVIsource("%mypath%\%mymovie%.avi") >> "%mypath%\%mpath%\T3\%mymovie%.avs"
echo ConvertToYV12(matrix="%rangepc%") >> "%mypath%\%mpath%\T3\%mymovie%.avs"
echo LoadPlugin("%mypath%\bin\autocrop.dll") >> "%mypath%\%mpath%\T3\%mymovie%.avs"
echo AutoCrop(0, 16, 16, threshold=0) >> "%mypath%\%mpath%\T3\%mymovie%.avs"

1184x666 uncompressed rgb24 with autocrop = 1184x656, matrix is PC.601

log in 4 minutes

Installing GDB.


avis [info]: 1184x656 @ 30.00 fps (2477 frames)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Slow
x264 [info]: profile High, level 3.2
[100.0%] 2476/2477 frames, 1.54 fps, 3852.15 kb/s, eta 0:00:00

Encoding X264 2nd Pass :

avis [info]: 1184x656 @ 30.00 fps (2477 frames)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Slow
x264 [error]: ratecontrol_init: can't open stats file
x264 [error]: x264_encoder_open failed

[juGGaKNot]

same stuff but --frames 120 works.

$ gdb /d/x264.exe
GNU gdb 5.2.1
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i686-pc-mingw32"...c:/cygmnt/prj/pkg/src/gdb/mingw32
/gdb/dwarf2read.c:985: gdb-internal-error: read_comp_unit_head: dwarf from non e
lf fil.

[Dark Shikari]

You still haven't answered my question.

[kemuri-_9]

and you're using a broken gdb, use release candidate 6.8-3

[juGGaKNot]

Updated to latest git, x264_hrd_pd_interlace.16.diff & x264_win_zone_parse_fix_06.diff, ./configure, fprofiled.

AVIsource("C:\x264\AVS2YUV.avi")
ConvertToYV12(matrix="PC.601")
LoadPlugin("C:\x264\bin\autocrop.dll")
AutoCrop(0, 16, 16, threshold=0)

AVS2YUV.exe AVS2YUV.avs -raw -o AVS2YUV.yuv

--preset veryslow --level %mylevel% --bitrate %btratex264% --stats "%mypath%\%mpath%\T1\movie.stats" --keyint %kint% --min-keyint %mint% --fullrange on --ref %myrefs% --bframes 0 --ratetol 2.0 --merange 32 --direct temporal --aq-mode 2 --no-fast-pskip --no-dct-decimate --vbv-bufsize 20000 --vbv-maxrate 20000 --nal-hrd --sar 1:1 --aud

avs bframes 0 : works
avs bframes 3 : crashes before last frame 2476/2477
yuv bframes 0 : works
yuv bframes 3 : works

TO DO :
updated to latest git, x264_hrd_pd_interlace.16.diff & x264_win_zone_parse_fix_06.diff, ./configure --enable-debug, fprofiled.

gdb /d/x264.exe
set args --preset veryslow --level 3.2 --bitrate 4000 --keyint 30 --min-keyint 30 --fullrange on --ref 5 --bframes 0 --ratetol 2.0 --merange 32 --direct temporal --aq-mode 2 --no-fast-pskip --no-dct-decimate --vbv-bufsize 20000 --vbv-maxrate 20000 --nal-hrd --sar 1:1 --aud
run
(wait for crash)
(post output)
bt
(post output)
disass $pc-30 $pc+30
(post this too)

./configure --enable-debug
gdb /d/x264.exe
set args --preset veryslow --level 3.2 --bitrate 4000 --keyint 30 --min-keyint 30 --fullrange on --ref 5 --bframes 3 --ratetol 2.0 --merange 32 --direct temporal --aq-mode 2 --no-fast-pskip --no-dct-decimate --vbv-bufsize 20000 --vbv-maxrate 20000 --nal-hrd --sar 1:1 --aud
run
(wait for crash)
(post output)
bt
(post output)
disass $pc-30 $pc+30
(post this too)

as soon as lord_mulder is on ... you know, you can take a n00b to water but you can't teach a noob how to drink.

[kemuri-_9]

as soon as lord_mulder is on ... you know, you can take a n00b to water but you can't teach a noob how to drink.

do what? what do you need LoRd_MuldeR for? you can do as we asked and that's that.

if you aren't going to post a bt we can't help the situation, but as you pointed at the it crashed with the .avs version of the source and not the .yuv,
the blame is likely with avisynth

don't post an entire post of '__TO_FILL_IN__', it's a waste of time to go through

[juGGaKNot]

i was waiting for help with gdb


Program exited normally.
(gdb)

gdb /d/x264.exe

set args --preset veryslow --level 3.2 --bitrate 4000 --frames 120 --keyint 30 --min-keyint 30 --fullrange on --ref 5 --bframes 0 --ratetol 2.0 --merange 32 --direct temporal --aq-mode 2 --no-fast-pskip --no-dct-decimate --vbv-bufsize 20000 --vbv-maxrate 20000 --nal-hrd --sar 1:1 --aud --output null d:/avs.avs

run

[kemuri-_9]

i was waiting for help with gdb

what help do you need? you have the entire sequence of commands to run to produce the bt...

Program exited normally.
we only want the bt for the case in which it crashes.
if it doesn't crash, it's just a waste of space to post the gdb output.

[juGGaKNot]

what help do you need? you have the entire sequence of commands to run to produce the bt...

Program exited normally.
we only want the bt for the case in which it crashes.
if it doesn't crash, it's just a waste of space to post the gdb output.

i had the old version, when you said get the new one i had to go, i came back ~20 minutes ago.

so there is no problem ? should i reinstall avysinth ?

[Revgen]

I'm doing some test encodes using Ben Waggoner's Island trailer he posted in the BD replication thread.

I've been having VBV underflow issues using 1222 build of x264 using these general settings.

x264 --profile high --level 4.1 --ssim --pass 2 --bitrate 40000 --stats "E:\King.stats" --thread-input --deblock -2:-2 --keyint 24 --min-keyint 2 --b-adapt 2 --direct auto --ref 4 --ipratio 1.1 --pbratio 1.1 --vbv-bufsize 30000 --vbv-maxrate 40000 --qcomp 0.5 --me umh --subme 9 --psy-rd 1.0:0.15 --partitions all --trellis 2 --no-mixed-refs --mvrange 511 --nal-hrd --aud --sar 1:1 --fullrange off --colorprim bt709 --colormatrix bt709 --transfer bt709 -o "g:\island.264" "g:\island.avs"

Using Jeeb's patched 1222 32-bit build, I always get 1 vbv error near the end of the encode. It doesn't matter if I use mbtree or not or use nal-hrd/aud or not. Komisar's generic 32-bit 1222 build doesn't give an error when I don't use mbtree, but it does give me one when I do use it.

[Dark Shikari]

Find a minimal set of settings that reproduces the problem, including minimizing the number of threads, if possible. Then, find the minimal number of frames necessary to replicate the problem and upload that specific section.