[x264-devel] [BUG] segfault when second pass has more frames than the first

[Corey Hickey]

Jason Garrett-Glaser wrote:
> On Mon, Feb 15, 2010 at 3:40 PM, Corey Hickey <bugfood-ml at fatooh.org> wrote:
>> Jason Garrett-Glaser wrote:
>>> On Mon, Feb 15, 2010 at 2:16 PM, Corey Hickey <bugfood-ml at fatooh.org> wrote:
>>>> Jason Garrett-Glaser wrote:
>>>>> On Mon, Feb 15, 2010 at 12:22 AM, Corey Hickey <bugfood-ml at fatooh.org> wrote:
>>>>>> Hello,
>>>>>>
>>>>>> I ran into this segfault while I was trying to figure out another bug,
>>>>>> and thought I'd see if I could fix it. I know that second passes should
>>>>>> have the same number of frames as the first, but x264 appears to have
>>>>>> code to handle this already, and that code just isn't quite working.
>>>>> Fixed in http://git.videolan.org/?p=x264.git;a=commit;h=bb0990813c7fb047a322c5d463cde5ae8e22c756
>>>> Many thanks. I still get a segfault with my test case, though--it's in a
>>>> different place now.
>>>>
>>>> $ mencoder -demuxer rawvideo -rawvideo w=16:h=16 /dev/zero \
>>>>  -o /dev/null -ovc x264 -x264encopts pass=1:bitrate=200 -frames 1
>>>>
>>>> $ mencoder -demuxer rawvideo -rawvideo w=16:h=16 /dev/zero \
>>>>  -o /dev/null -ovc x264 -x264encopts pass=2:bitrate=200 -frames 2
>>>>
>>>> Program received signal SIGSEGV, Segmentation fault.
>>>> 0x0000000000c5634b in x264_weight_cost_init_luma (h=0x1663510,
>>>> fenc=0x188b8d0, ref=0x187d130,
>>>>    dest=0x1852bb0 "") at encoder/slicetype.c:93
>>>> 93          if( fenc->lowres_mvs[0][ref0_distance][0][0] != 0x7FFF )
>>>> (gdb) print ref0_distance
>>>> $14 = 1
>>>> (gdb) print fenc->lowres_mvs[0][ref0_distance]
>>>> $15 = (int16_t (*)[2]) 0x0
>>>>
>>>> It would appear that these are only allocated if h->frames.b_have_lowres
>>>> at common/frame.c:136.
>>>>
>>>> I've attached a more complete gdb log, in case it's useful.
>>>>
>>>> Thanks again,
>>>> Corey
>>> Try disabling weightp.
>> It seems to work with weightp=0 or weightp=1.
>>
>> I found another issue: if I use pass=3 for the second pass, the stats
>> file isn't usable for the third pass.
>>
>> $ mencoder -demuxer rawvideo -rawvideo w=16:h=16 /dev/zero \
>>  -o /dev/null -ovc x264 -x264encopts pass=1:bitrate=200:weightp=0 \
>>  -frames 1
>>
>> $ mencoder -demuxer rawvideo -rawvideo w=16:h=16 /dev/zero \
>>  -o /dev/null -ovc x264 -x264encopts pass=3:bitrate=200:weightp=0 \
>>  -frames 2
>>
>> $ mencoder -demuxer rawvideo -rawvideo w=16:h=16 /dev/zero \
>>  -o /dev/null -ovc x264 -x264encopts pass=3:bitrate=200:weightp=0 \
>>  -frames 2
>>
>> That last command has the error:
>> x264 [error]: bad frame number (2) at stats line 1
>>
>> The log file has a line for each frame (truncated for readability):
>> in:0 out:0 type:I ...
>> in:2 out:1 type:P ...
>>
>> I've attached the full 2-pass log from the second pass.
>>
>>
>> Again, I know this isn't really a useful case, but I found the bugs and
>> thought I should point them out.
>>
>> Thanks,
>> Corey
>>
>> #options: 16x16 fps=25/1 cabac=1 ref=3 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=7 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-2 threads=1 sliced_threads=0 nr=0 decimate=1 mbaff=0 constrained_intra=0 bframes=3 b_pyramid=0 b_adapt=1 b_bias=0 direct=1 wpredb=1 wpredp=0 keyint=250 keyint_min=25 scenecut=40 intra_refresh=0 rc_lookahead=40 rc=2pass mbtree=1 bitrate=200 ratetol=1.0 qcomp=0.60 qpmin=10 qpmax=51 qpstep=4 cplxblur=20.0 qblur=0.5 ip_ratio=1.40 aq=1:1.00
>> in:0 out:0 type:I q:21.00 tex:118 mv:13 misc:5125 imb:1 pmb:0 smb:0 d:- ref:;
>> in:2 out:1 type:P q:24.00 tex:0 mv:0 misc:96 imb:0 pmb:0 smb:1 d:- ref:0 ;
> 
> This is intentional.  A statsfile will never have more frames than
> there were on the first pass.

Then shouldn't there be only one line after the #options? In this case,
there was 1 frame in the first pass and 2 in the second and third. The
third pass fails unless I manually remove the line corresponding to the
second frame or change the "in:2" to "in:1".

-Corey