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

[Jason Garrett-Glaser]

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.

Dark Shikari