2nd pass has more frames than 1st pass

[Deckard]

First time, it happens for me :

Code: Select all

Encoding: task 2 of 2, 99.98 % (84.83 fps, avg 54.94 fps, ETA 00h00m02s)x264 [error]: 2nd pass has more frames than 1st pass (178522)
x264 [error]: continuing anyway, at constant QP=24
x264 [error]: 2nd pass has more frames than 1st pass (178522)
x264 [error]: continuing anyway, at constant QP=24
x264 [error]: 2nd pass has more frames than 1st pass (178522)
x264 [error]: continuing anyway, at constant QP=24
assertion "h->frames.b_have_lowres" failed: file "encoder/slicetype.c", line 376

Encoding: task 2 of 2, 100.00 % (86.17 fps, avg 54.95 fps, ETA 00h00m00s)    200 [sig] hbcli 2376 open_stackdumpfile: Dumping stack trace to hbcli.exe.stackdump

 363857 [sig] hbcli 2376 C:\Program Files\_EncTools\Handbrake\hbcli.exe: *** fatal error - called with threadlist_ix -1

Stackdump :

Code: Select all

Stack trace:
Frame     Function  Args
0022CA78  7C802451  (000000C8, FFFFFFFF, 0022CC38, 004014E7)
0022CA88  00412314  (000000C8, 0022CC18, 0022C9D0, 0022C9B0)
0022CC38  004014E7  (0000001C, 00EE0F08, 00EE0090, 00000002)
0022CD98  61006198  (00000000, 0022CDD0, 61005510, 0022CDD0)
61005510  61004416  (0000009C, A02404C7, E8611001, FFFFFF48)
 363857 [sig] hbcli 2376 C:\Program Files\_EncTools\Handbrake\hbcli.exe: *** fatal error - called with threadlist_ix -1

Does anybody can post last hbcli.exe ? I don't have compile tools right now ...
Thank you.

[jbrjake]

How do you think anyone can possibly help you as long as you refuse to include basic information like what settings you're using?

At least when GUI users try to force us to read their minds, they have the excuse of laziness -- they have to transcribe the setting of every widget.

You, though, could have just pasted in the command line string you used. It would have taken 5 seconds. But apparently that was too much effort?

[Deckard]

sr55 was nicer when I helped him debugging HB :
http://handbrake.m0k.org/forum/viewtopic.php?t=2668
http://handbrake.m0k.org/forum/viewtopic.php?t=2610

How do you think anyone can possibly help you as long as you refuse to include basic information like what settings you're using?

It's me who wants to help. I can use a lot of other tools instead of HB ...

But apparently that was too much effort?

To help is always a pleasure for me, not an effort ...

Indeed, command line was :
hbcli -i "PATH\TO\VIDEO_TS" -t 1 -c 1-28 -o "PATH\TO\MP4" -e x264 -E faac -w 720 -s 1 -b 1200 -2 -B 128 -R 44.1 -a 1 -6 stereo

[s55]

Deckard - http://handbrake.m0k.org/forum/viewtopic.php?t=143

Really, if you want to be of help, you need to post everything listed above.
It is very rare that one can diagnose a problem based on a hunch. Also the WinGUI is a damn sight less complicated (with less error message handling built in and therefore I can't expect full debug reports from users)

fyi - stack dumps are useless. Ya see how it looks like just a bunch of numbers and has no real information.... well..... thats what we see to
(for future reference)

[jbrjake]

Hrm....no x264 options, but different frame counts? Odd.

I suppose it could be some kind of multithreading bug in x264, though I think I'd have heard of one of it was there...

Try setting -C 1 to force HB to use 1 processor or -x threads=1 to set just x264 to use 1 processor, see if that helps...

Also, what version of HB are you using?

[Deckard]

I'm using official 0.9 CLI version. No GUI, CLI only.

I always encode sources with 1 title, 1 video track, 1 audio track, 1 subtitle track.
Same command line works great with others sources.

[Aggemam]

I've just encountered that exact same problem, using the GUI. I'll run the encoding again with the same settings, to see if it was just a random occurrence.

[sphoid]

I have been experiencing this problem frequently as well.

I am using official 0.9.2 CLI version on a Core2 Duo

Commandline i use is
HandBrakeCLI -i /dev/cdrom1 -o <nameofmovie>.mkv -e x264 -b 1000 -T -E ac3 -a1 -t1 -p -2

I am now testing with it forced to 1 cpu. I'm curious to know if the cause of this was ever determined. It's happened to me 4 or 5 times in the last couple of days so you can imagine its pretty annoying to hit 95% on the second pass and have it bomb out. It typically happens between 95% and 99%

Here is the error:

Encoding: task 2 of 2, 91.52 % (43.54 fps, avg 40.36 fps, ETA 00h05m01s)x264 [error]: 2nd pass has more frames than 1st pass (130914)
x264 [error]: continuing anyway, at constant QP=23
x264 [error]: 2nd pass has more frames than 1st pass (130914)
x264 [error]: continuing anyway, at constant QP=23
x264 [error]: 2nd pass has more frames than 1st pass (130914)
x264 [error]: continuing anyway, at constant QP=23
HandBrakeCLI: encoder/slicetype.c:375: x264_slicetype_analyse: Assertion `h->frames.b_have_lowres' failed.
Aborted (core dumped)

[jbrjake]

Hmm...I made two different changes for 0.9.2 to keep that from happening...guess it didn't work

[sphoid]

This issue has become very frustrating. I am considering rolling back to 0.9.1 as this error is occuring almost every other encode and I never had this problem until i upgraded to 0.9.2. Will there be any resolution to this or a new version soon?

[jbrjake]

Well as I said, this isn't a new problem, it was one that existed in 0.9.1 -- really, it's existed as long as the Turbo option's been around.

The only thing I can tell you is to not use Turbo, and that the next release, which is not imminent, will have slower Turbo options that are less likely to make something like that happen. At least, that's if it's being caused by Turbo. It could be caused by something else, like some frames not getting flushed somewhere. If that's happening, then all I can say is to not use 2-pass for the time being.

I can't reproduce the problem using a short test sample and your given cli string or the Normal preset...

[maestro371]

I'm not using Turbo and frequently (about 2 minutes ago was the last instance) see this issue with 0.9.2. I use a quad core (2 Xeon 5030 processors) Ubuntu VM paravirtualized on Xen with access to all 4 cores. Sometimes it happens at around 99% - other times (like that posted below) it gets to 100% but still fails. This happens on about 33% of my encodes. I generally just switch to my Mac and re-encode the problem files (it's far slower than the Linux box).

HandBrakeCLI -i ./MOVIE -t1 -o ~/movie.mp4 -2 -I -e x264 -b 2500 -E aac -f mp4 -4 -m -p -x bframes=3:ref=1:subme=5:me=umh:no-fast-pskip=1:trellis=1:cabac=0

Code: Select all

HandBrake 0.9.2 (2008021900) - http://handbrake.m0k.org/
4 CPUs detected
Opening ./MOVIE...
<snip>
x264 [info]: using cpu capabilities: MMX MMXEXT SSE SSE2 Cache64 
Encoding: task 1 of 2, 100.00 %No accelerated IMDCT transform found
Encoding: task 2 of 2, 100.00 %x264 [error]: 2nd pass has more frames than 1st pass (63326)
x264 [error]: continuing anyway, at constant QP=18
x264 [error]: disabling adaptive B-frames
Encoding: task 2 of 2, 100.00 %x264 [error]: 2nd pass has more frames than 1st pass (63326)
x264 [error]: continuing anyway, at constant QP=18
x264 [error]: disabling adaptive B-frames
x264 [error]: 2nd pass has more frames than 1st pass (63326)
x264 [error]: continuing anyway, at constant QP=18
x264 [error]: disabling adaptive B-frames
x264 [error]: 2nd pass has more frames than 1st pass (63326)
x264 [error]: continuing anyway, at constant QP=18
x264 [error]: disabling adaptive B-frames
x264 [error]: 2nd pass has more frames than 1st pass (63326)
x264 [error]: continuing anyway, at constant QP=18
x264 [error]: disabling adaptive B-frames
x264 [error]: 2nd pass has more frames than 1st pass (63326)
x264 [error]: continuing anyway, at constant QP=18
x264 [error]: disabling adaptive B-frames
HandBrakeCLI: encoder/slicetype.c:375: x264_slicetype_analyse: Assertion `h->frames.b_have_lowres' failed.
</snip>

[jbrjake]

Use newer code.

http://forum.handbrake.fr/viewtopic.php?f=5&t=5722

[maestro371]

I downloaded the latest code via SVN and am trying it out now. It appears to be dramatically slower (it's encoding at 9.19 fps right now when I'm used to seeing about 29 fps on this machine) than 0.9.2 - is that to be expected for pre-release code? It also reports that it's "x264 [info]: using cpu capabilities: none!".

I understand that this is not "supported" code, so if your answer is along those lines I get it.

Thanks!

[maestro371]

Hmm. Now I'm really confused. x264 is complaining about not having yasm:

Code: Select all

ibX264 contrib/lib/libx264.a 
patching file encoder/slicetype.c
Hunk #1 succeeded at 376 (offset -3 lines).
patching file common/frame.c
patching file common/frame.h
patching file encoder/encoder.c
patching file encoder/ratecontrol.c
patching file encoder/ratecontrol.h
No suitable assembler found.  x264 will be several times slower.
Please install 'yasm' to get MMX/SSE optimized code.
./version.sh: 2: git-rev-list: not found
Platform:   X86
System:     LINUX
avis input: no
mp4 output: no
pthread:    yes
gtk:        no
debug:      no
gprof:      no
PIC:        no
shared:     no
visualize:  no

. . . despite the fact that I have it installed and available:

Code: Select all

me@ubuntu:/opt/svn/HandBrake$ which yasm
/usr/bin/yasm
me@ubuntu:/opt/svn/HandBrake$ yasm --version
yasm 0.5.0.1591
Compiled on Mar 28 2007.
Copyright (c) 2001-2006 Peter Johnson and other Yasm developers.
Run yasm --license for licensing overview and summary.

Is there a specific version of yasm that I need?

[maestro371]

Ah - got it. Compiled the latest yasm (0.7.99) from SVN and used that for compiling HandBrake. That seemed to do the trick:

Code: Select all

x264 [info]: using cpu capabilities: MMX MMX2 SSE SSE2 SSE3 Cache64
Encoding: task 1 of 2, 10.02 % (60.10 fps, avg 63.69 fps, ETA 00h14m54s)

[TedJ]

You may also want to look at this thread from the Development forum... If you're in the habit of building from SVN, it's worthwhile to browse through there occasionally - just remember, no posting there unless you've something to contribute.

From what I can see, you appear to be missing SSSE3 optimisations on your current build.

[maestro371]

Thanks for the tips - I'll check that thread out.

On SSSE3, I don't think the Xeon 5030s have that extension ( at least they aren't listed on the wikipedia article about it: http://en.wikipedia.org/wiki/SSSE3 ).