[x264-devel] Yet another updated threaded slicetype patch (v14)

Steven Walters kemuri9 at gmail.com
Wed May 27 01:46:54 CEST 2009


OK, so i took a deeper crack at this a couple days ago when some time
came around...

the problem i was seeing that within
encoder\lookahead.c - void x264_lookahead_thread( x264_t *h )
upon entering the function h->rc is a valid non-null pointer.
However, after entering and leaving the
while ( h->lookahead->ifbuf.i_size == 0 && h->lookahead->b_exit_thread == 0 )
branch, h->rc becomes NULL.

as a small hack workaround, i tried storing h->rc into a local variable and
set h->rc to the stored value before executing
_x264_lookahead_slicetype_decide( h );

it then successfully passed down h->rc to
x264_ratecontrol_slice_type (h, ...)

but it still seg faulted even with that.

turning to valgrind at this point gets me the following output (on a
debian box):
==13777== Thread 2:
==13777== Invalid read of size 4
==13777==    at 0x8095AFA: x264_ratecontrol_slice_type (ratecontrol.c:1012)
==13777==    by 0x8073414: x264_slicetype_decide (slicetype.c:608)
==13777==    by 0x8056CA3: (within /home/kemuri/projects/x264/x264test)
==13777==    by 0x809A86F: _x264_lookahead_slicetype_decide (lookahead.c:321)
==13777==    by 0x809AB5F: x264_lookahead_thread (lookahead.c:413)
==13777==    by 0x405023F: start_thread (in
/lib/tls/i686/cmov/libpthread-2.3.6.so)
==13777==    by 0x412849D: clone (in /lib/tls/i686/cmov/libc-2.3.6.so)
==13777==  Address 0xDC is not stack'd, malloc'd or (recently) free'd
==13777==
==13777== Process terminating with default action of signal 11 (SIGSEGV)
==13777==  Access not within mapped region at address 0xDC
==13777==    at 0x8095AFA: x264_ratecontrol_slice_type (ratecontrol.c:1012)
==13777==    by 0x8073414: x264_slicetype_decide (slicetype.c:608)
==13777==    by 0x8056CA3: (within /home/kemuri/projects/x264/x264test)
==13777==    by 0x809A86F: _x264_lookahead_slicetype_decide (lookahead.c:321)
==13777==    by 0x809AB5F: x264_lookahead_thread (lookahead.c:413)
==13777==    by 0x405023F: start_thread (in
/lib/tls/i686/cmov/libpthread-2.3.6.so)
==13777==    by 0x412849D: clone (in /lib/tls/i686/cmov/libc-2.3.6.so)

so it does seem that the lookahead thread might need to allocate it's
own ratecontrol_t
what are the others' thought at this point?


More information about the x264-devel mailing list