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

[Jason Garrett-Glaser]

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.

Dark Shikari