x264 error: 'Slicetype lookahead doesn't work with bframes=0'?

[simonhowson]

I received a strange x264 error when converting a Blu-ray sourced HD VC1 file to MeGUI iPhone profile format H.264:

http://img39.imageshack.us/img39/1235/x264error.gif

Here is my script:

# Set DAR in encoder to 16 : 9. The following line is for automatic signalling
global MeGUI_darx = 16
global MeGUI_dary = 9
DirectShowSource("L:\howthe\howthe.track_4113-muxed.mkv", fps=23.976, audio=false, convertfps=true)
#deinterlace
crop( 2, 0, -2, 0)

LanczosResize(640,368) # Lanczos (Sharp)
#denoise


I converted the same source today to MPEG2 with no problems.

Any ideas what caused this? The encode crashed at the end of the first pass, after about 3 hours.

[Trahald]

I havent used megui in a while, but looking at the output it looks like there was a successful first pass but Megui saw the error message and didnt attempt a second. the first pass should have produced usable first pass statistics and been able to do a second pass fine.

btw..what crashed?

[roozhou]

Are you using x264 r1153?

[simonhowson]

I havent used megui in a while, but looking at the output it looks like there was a successful first pass but Megui saw the error message and didnt attempt a second. the first pass should have produced usable first pass statistics and been able to do a second pass fine.
In the queue is has ERROR next to the first pass, and the second is stuck on waiting.

Is there anyway I can start the second pass using the statistics of the first?

btw..what crashed?
I assumed x264 had crashed. I came back in the room and the encoder window was gone. I guess it could've just finished abnormally.
Are you using x264 r1153?
Yes "1153 Skystrife's Patched Build".

I did an update before starting encoding, and that was the version it downloaded.

[Dark Shikari]

Erm, why are you using a build with an unsupported and incomplete patch that is known to have bugs on Windows?

[Audionut]

Erm, why are you using a build with an unsupported and incomplete patch that is known to have bugs on Windows?

MeGUI is using it as it's build.

[Dark Shikari]

MeGUI is using it as it's build.Are they insane? It's one thing to use bleeding-edge builds, it's another thing to use ones actually known to be broken!

[Audionut]

My guess is that they are using a script to grab any builds posted by skystrife.

Only problem is that skystrife has uploaded the build in question.
In the current patches thread, he doesn't have a unpatched x86 build.

edit: and techouse is using some pretty funky patches too.
Guess MeGUI should go back to using unpatched x264.nl builds.

[Kurtnoise]

My guess is that they are using a script to grab any builds posted by skystrife.
wrong guess and don't count on me on the "they"...

Guess MeGUI should go back to using unpatched x264.nl builds.
the only one patch required (coz used in some presets) is the one from Trahald...

[Audionut]

don't count on me

Can you not override the build being sent by update?

[Kurtnoise]

no, I can't...

[Trahald]

@ Skystrife
Can you make a separate build with the more experimental patches and keep it separate (different filename) from the other moded build (hrd and winzone)?

[Comatose]

Just wanted to post about this... I just updated x264 through MeGUI too, and got this. Got a x264.nl build and it works =\

[MixMasters]

here is mine
http://i39.tinypic.com/288r3uc.png


[Error] 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 X2 Dual Core Processor 3600+
-[Error] Log for job1 (video, [Leopard-Raws] FULLMETAL ALCHEMIST 2009 - 07 RAW (D-TBS x264 AAC 1280x720).avs -> )
--[Information] [5/20/2009 10:08:25 PM] Started handling job
--[Information] [5/20/2009 10:08:25 PM] Preprocessing
--[NoImage] Job commandline: "C:\Program Files\megui\tools\x264\x264.exe" --pass 1 --bitrate 984 --stats "E:\[Leopard-Raws] FULLMETAL ALCHEMIST 2009 - 07 RAW (D-TBS x264 AAC 1280x720).stats" --level 3.1 --subme 2 --partitions none --me dia --threads auto --thread-input --sar 1:1 --progress --no-psnr --no-ssim --output NUL "E:\[Leopard-Raws] FULLMETAL ALCHEMIST 2009 - 07 RAW (D-TBS x264 AAC 1280x720).avs"
--[Information] [5/20/2009 10:08:27 PM] Encoding started
--[Error] An error occurred: x264 [error]: currently slicetype lookahead does not work with bframes=0 and is disabled
--[NoImage] Standard output stream
--[NoImage] Standard error stream
---[NoImage] avis [info]: 848x480 @ 23.98 fps (35238 frames)
---[NoImage] x264 [info]: using SAR=1/1
---[NoImage] x264 [info]: using cpu capabilities: MMX2 SSE2Slow
---[NoImage] x264 [info]: profile Main, level 3.1
---[NoImage]
---[NoImage] x264 [info]: slice I:346 Avg QP:14.42 size: 39394
---[NoImage] x264 [info]: slice P:34892 Avg QP:17.31 size: 4880
---[NoImage] x264 [info]: mb I I16..4: 38.6% 0.0% 61.4%
---[NoImage] x264 [info]: mb P I16..4: 9.1% 0.0% 0.0% P16..4: 44.2% 0.0% 0.0% 0.0% 0.0% skip:46.7%
---[NoImage] x264 [info]: final ratefactor: 22.06
---[NoImage] x264 [info]: coded y,uvDC,uvAC intra:35.8% 54.0% 27.8% inter:11.0% 27.6% 1.4%
---[NoImage] x264 [info]: kb/s:1001.1
---[NoImage] encoded 35238 frames, 10.53 fps, 1001.12 kb/s
--[Information] [5/20/2009 11:04:15 PM] Job completed

[roozhou]

It seems MeGUI will catch any "x264 [error]" and treat them as an error in x264. It's better to determine on the return value of the process.
Well that's easy to fix:

Index: encoder/lookahead.c
===================================================================
--- encoder/lookahead.c
+++ encoder/lookahead.c
@@ -176,7 +176,7 @@
sprintf(h_lookahead->unused.name, "unused");
if ( h->param.i_bframe == 0 )
{
- x264_log( h, X264_LOG_ERROR, "currently slicetype lookahead does not work with bframes=0 and is disabled\n");
+ x264_log( h, X264_LOG_WARNING, "currently slicetype lookahead does not work with bframes=0 and is disabled\n");
h->param.rc.i_lookahead = 0;
return X264_SUCCESS;
}

[LoRd_MuldeR]

Still MeGUI shouldn't ship with a x264 build that contains an highly experimental patch. At least not by default and not without a big fat warning.

[skystrife]

@ Skystrife
Can you make a separate build with the more experimental patches and keep it separate (different filename) from the other moded build (hrd and winzone)?

http://forum.doom9.org/showpost.php?p=1287982&postcount=1866

^-- there you go. Hopefully that'll get added to the auto-update soon. Sorry for the problems!

[skystrife]

Oh, pfft. I figured out the real problem with the crashing, I believe--when I restructured my mingw environment for gcc 4.4.0, somehow a shared version of libpthread decided to build with the x86 version. I've fixed it, and if I were to rebuild I bet that would solve the issue of it crashing immediately after starting encoding, but not when the whole pass is finished, unless the "crash" is not actually a crash and people reporting the error flagged by MeGUI (x264 is crashing if you get that lovely "x264 has stopped responding" window from the OS, but if not I think it's closing just fine). Either way, I'll make sure to distinguish the builds using lookahead in the future, though I'm convinced that with the windows fix and gcc 4.x+ the problems with it are fixed.

[simonhowson]

Erm, why are you using a build with an unsupported and incomplete patch that is known to have bugs on Windows?
I'm sorry, I really don't know much about different versions of x264, I just use whatever MeGUI downloads from its 'stable' server.
Still MeGUI shouldn't ship with a x264 build that contains an highly experimental patch. At least not by default and not without a big fat warning.
This would be good for people like me who don't keep track of all the new patches. I mean I just assumed that the versions coming from the STABLE server would be, well, stable.

http://forum.doom9.org/showpost.php?p=1287982&postcount=1866

^-- there you go. Hopefully that'll get added to the auto-update soon. Sorry for the problems!
I'll give this version a go as well.

[ndoggac]

I had this same problem due to v1153 of x264. Resolved it by downloading v1148 and replacing the x264 executable that MeGui references. Also required a rename in my case.
File is under C:\Program Files\megui\tools\x264 Replace existing x264.exe (v1153) with old one (v1148). Worked like a charm.

[Sharktooth]

1153-2 should fix the issue.

[goldplated]

I was getting encoding errors with 1153-2. just updated to 1153-3. Working now.