x264 cli bugreports

[Stereodude]

Originally Posted by Dark Shikari

I see your machine supports AVX2; could you update to the latest build (r2345 or so?) to make sure it wasn't that denoise_dct alignment issue I just fixed?

Ok, I tried r2345 x64 (clean, from Komisar) and it works fine / no crash. I didn't realize that the r2334 posted on x264.nl wasn't the latest version.

[LoRd_MuldeR]

Originally Posted by Stereodude

I figured it out. Your instructions are for debugging the x86 x264 binary, not the x64 one I originally tried. It's running now.

I was pointing to 32-Bit MinGW (containing a 32-Bit GDB), but for debugging a 64-Bit binary you probably have to grab the GDB from the 64-Bit MinGW package.

Originally Posted by Stereodude

Well, this doesn't seem very useful, but maybe with a .map file it makes more sense?
So... Where can I get a debug build?

Building x264 from the sources isn't very difficult, as long as you don't want all the extra libraries. Especially if software development isn't completely new for you.

It seems you already solved your problem this time, but next time you may need a debug build, just grab MinGW + MSYS and then in the MSYS terminal do the following:

git clone git://git.videolan.org/x264.git x264-src
cd x264-src
./configure --enable-win32thread --enable-debug
make

Note that the "--enable-win32thread" is needed with the latest MinGW builds, as the PThreads it includes performs very poor with x264 for whatever reason, like ~0.5 fps.

(Your mileage may vary)

Originally Posted by Stereodude

I didn't realize that the r2334 posted on x264.nl wasn't the latest version.

In the absence of Sharktooth, I have updated the sticky a bit, hopefully this helps to avoid confusion...

[Groucho2004]

Originally Posted by jq963152

Is that intended?

I'm sure that whoever built the binaries disabled GPAC (and FFMS) on purpose. Also, this is not really a bug report.

[Chainmax]

I'm currently trying to use JEEB's 32bit r2245 x264 build to encode a fairly resource-intensive script. For the third time, the encode seems to stop at about 66%. The process does not get hung and it does not crash, but the progress indicator just stops increasing. What could be the cause of this? I am using AVISynth v 2.60a4 and SEt's v2.6MT.

[turbojet]

Originally Posted by Chainmax

I'm currently trying to use JEEB's 32bit r2245 x264 build to encode a fairly resource-intensive script. For the third time, the encode seems to stop at about 66%. The process does not get hung and it does not crash, but the progress indicator just stops increasing. What could be the cause of this? I am using AVISynth v 2.60a4 and SEt's v2.6MT.

Are you using SetMTMode?

[Chainmax]

Yes. Should I try eliminating all related lines, or just the Distributor() one?

[Groucho2004]

Originally Posted by Chainmax

Yes. Should I try eliminating all related lines, or just the Distributor() one?

- Post your script
- Don't use Distibutor() in the script
- How much memory does Avisynth use with your script?
- Post your x264 command line

[Chainmax]

Yeah, my bad. Here's the script:

SetMemoryMax(900)

SetMTMode(5,4)

Plugin loading

MPEG2Source("x:\wherever\somevideo.d2v")

SetMTMode(2)

TComb(fthreshL=6,fthreshC=7,othreshL=7,othreshC=8)

source=last
out1=source.Checkmate()
out2=source.checkmate(tthr2=0)
out2.mergechroma(out1)

FFT3DFilter(sigma=10,plane=3,bw=32,bh=32,bt=3,ow=16,oh=16,interlaced=true)

Interp = nnedi3()
Deinted=TDeint(type=1,edeint=Interp,emask=TMM())
TFM(d2v="x:\wherever\somevideo.d2v",mode=6,PP=7,slow=2,mChroma=true,Clip2=Deinted)
vinverse()
TDecimate(mode=1)

RemoveGrain(mode=5)

p=last
a=p.Trim(0,32578)
b=p.Trim(32579,32654).ConvertToYUY2().SpatialSoften(11,0,700).SpatialSoften(11,0,700).ConvertToYV12().ChubbyRain2().FFT3DFilter(sigma=16,plane=3,bw=32,bh=32,bt=3,ow=16,oh=16)
c=p.Trim(32655,0)
a+b+c

q=last
d=q.Trim(0,34603).Crop(6,2,704,478,align=true)
e=q.Trim(34604,0).ConvertToRGB().Crop(7,2,703,478,align=true).Spline36Resize(704,478).ConvertToYV12()
d+e

source=last
preNR=source.dfttest(sigma=1.25,tbsize=3).FFT3DFilter(sigma=10,plane=3,bw=32,bh=32,bt=3,ow=16,oh=16)
preNR_super=preNR.MSuper(pel=2, sharp=1)
source_super=source.MSuper(pel=2, sharp=1)
backward_vec3 = MAnalyse(preNR_super,isb = true, delta = 3, overlap=4)
backward_vec2 = MAnalyse(preNR_super,isb = true, delta = 2, overlap=4)
backward_vec1 = MAnalyse(preNR_super,isb = true, delta = 1, overlap=4)
forward_vec1 = MAnalyse(preNR_super,isb = false, delta = 1, overlap=4)
forward_vec2 = MAnalyse(preNR_super,isb = false, delta = 2, overlap=4)
forward_vec3 = MAnalyse(preNR_super,isb = false, delta = 3, overlap=4)
source.MDegrain3(source_super,backward_vec1,forward_vec1,backward_vec2,forward_vec2,backward_vec3,forward_vec3,thSAD=350)

RemoveGrain(mode=5)

Spline36Resize(704,480)
aWarpSharp2(depth=16,chroma=4)

dull=last
sharp=last.LimitedSharpenFaster(SMode=4,Strength=150)
Soothe(sharp,dull,25)

Tweak(sat=1.1)

GradFunkMirror(1.51)

Task Manager reports around 1.5GB being used by x264. The command line is not too involved, but it is overkill:

x264-10bit --preset placebo --tune animation --bframes 16  --crf 18 --keyint 240 --no-dct-decimate 
--no-fast-pskip --output d:\result.mp4 d:\wherever\sauce.avs

About the Distributor() line, what little I read about it was that it was not necessary to include on the script, and removing it might solve issues every now and then. What is its utility then? Are there an cases where it's worth including it n the script?

[Groucho2004]

Woah. With that script, Avisynth MT and the placebo preset it's no surprise that it locks up.
The script alone with Avisynth MT probably needs already 2 G which leaves nothing for the encoder.

I'd start by tuning the script so it runs with reasonable speed and not too much memory. Use MDegrain2 instead of 3. Play with SetMemoryMax().

Use AVSMeter to monitor the memory usage and speed.

The Distributor() call is only necessary for some piping tools and ffdshow. x264 invokes the call itself.

Edit:
Your problem is most likely related to Avisynth(MT) so maybe this should moved to the appropriate thread.

[cretindesalpes]

Indeed your script is very heavy (cascade of temporal filters). Does the 66 % correspond to a Trim in your script (frame 32579, 34604...)? You probably have a new filter chain suddenly kicking in and generally the AVS-MT cache doesn't like that, outputing a frame every minute or so if you’re lucky.

[MrVideo]

Win7-64
x264 x86 Win32 versions: 2851, 2893, 2901
Downloaded from: x264.nl

Problem: when using 2893, or 2901, with AVISynth, x264 complains that it "failed to load avisynth." 2851 works without any issues.

When running the --version option, I notice that 2851 has the --bit-depth=8 configuration option, while 2893 and 2901 do not. Is that the reason why neither version can find avisynth, even though it is there?

Can the next x264 Win32 binary release get fixed so that it will again work with AVISynth?

Update: I've discovered another location for a 2901 download: LigH's x264 (https://www.mediafire.com/?bxvu1vvld31k1)
It too doesn't contain the --bit-depth=8 configuration option, but it works.

Any particular reason why the x264.nl versions fail and the LigH's version works?

[MasterNobody]

Do official builds from videolan works? For me both win32 and win64 builds work without problems with AviSynth demuxer. Also check which version of AviSynth you have (original or AviSynth+ and which revision) and that you use have both 32-bit and 64-bit AviSynth installed i.e. you not trying to run win64 x264 build with win32 AviSynth or vice versa. Try to run both win32 and win64 builds.

[MrVideo]

My mistake, in that I said the builds were from x264.nl. Those three were from the videolan repository. So no, they did not work.

AVISynth is 32bit 2.6 version. The version also required for BDRB. I can't test the Win64 build at the moment, as I have a compile currently running.

Update: The videolan 2901 x64 version had the same result.

[MasterNobody]

I can't replicate it here with:
Windows 7 64-bit
x264-r2901-7d0ff22.exe CRC32: A262BDF6 MD5: CC70693AD3E613ECBEEE178B578BCDFE
AviSynth_260.exe CRC32: D510D65E MD5: 7299618CCDFA57A2302381FD104234D6

Make sure that you run 32-bit x264 which have size of 20803584 bytes and not 64-bit x264 with same name but size of 22505472 bytes. Also I would recommend switch to AviSynth+ (as only developed/maintained fork) instead of AviSynth 2.6

[MrVideo]

Thanks. Making me recheck the files determined that all of the name changing (the long x264 binary name to x264.exe) and then renaming the x264.exe to x264-2901-x86.exe and x264-2901-x64.exe resulted in the x264-2901-x86.exe file actually being the x64 version. I do not know how I managed to screw this up when transferring the files from the storage area on the NAS. Unfortunately, running the programs with --help or --version results in no information about the binary being 32bit or 64bit. It didn't even dawn on me that the two files were the same size. I've since run "file" on each one (I have Cygwin installed) and see the result. That is now fixed.

As for the 2893 version, I somehow managed to download the x64 version and not the x86 version.

As for running AviSynth+, I can't do that. AFAIK, BDRB will not work with the + release. Jdobbs' thread only recommends installing the 2.60 version.