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

Corey Hickey bugfood-ml at fatooh.org
Tue Feb 16 00:40:25 CET 2010


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
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: divx2pass.log
URL: <http://mailman.videolan.org/pipermail/x264-devel/attachments/20100215/cdc08ca5/attachment.txt>


More information about the x264-devel mailing list