Michael <[EMAIL PROTECTED]> added the comment:
On 7/20/08, Michael Niedermayer <[EMAIL PROTECTED]> wrote:
>
> Michael Niedermayer <[EMAIL PROTECTED]> added the comment:
>
> On Sat, Jul 19, 2008 at 02:22:25AM +0000, Michael wrote:
>>
>> Michael <[EMAIL PROTECTED]> added the comment:
>>
>> > Well, The report, contains
>> > no gdb output (mandatory for crashes)
>> > no valgrind output (mandatory for memory issues)
>> > no patch (mandatory for any "fix")
>> > no sample file to reproduce
>> > it does contain some vague description of a crash and a bug that is not
>> > reproduceable.
>> > and a claim of an out of array access, which isnt out of the array as
>> > far as i can tell for ffmpeg and ffplay. It may be that the quoted
>> > code is wrong and that it is out of the allocated space for some
>> > applications. But honestly this is becoming quite a bit too
>> > speculative, especially considering that we have many well written
>> > bug reports which need to be dealt with.
>>
>> I appreciate it would be more useful to have all those things, but
>> there's a limit to the amount of time I can spend on this. I'm a long
>> way from a usable development machine, and I simply don't have that
>> data any more. The best I can do for you is try and explain as best as
>> I can what the bug is.
>>
>> Using line numbers from h264.c in the trunk (rev 14283).
>>
>> The function xchg_mb_border() contains the following code:
>>
>> 2304 : if(h->deblocking_filter == 2) {
>> 2305 : mb_xy = h->mb_xy;
>> 2306 : deblock_left = h->slice_table[mb_xy] ==
>> h->slice_table[mb_xy -
>> 1];
>> 2307 : deblock_top = h->slice_table[mb_xy] ==
>> h->slice_table[h->top_mb_xy];
>> 2308 : } else {
>> 2309 : deblock_left = (s->mb_x > 0);
>> 2310 : deblock_top = (s->mb_y > 0);
>> 2311 : }
>>
>> Assume h->deblocking_filter != 2 (Which is true for my videos).
>>
>> The first time this routine is called for a given field, it has src_y
>> == &buffer[0] (the start of the image buffer).
>
> no, it is 16 lines after the start of the image buffer. And this is why
> i would like to have a little more information about this. I dont dispute
> the code is wrong and your suggested fix is correct, its just that things
> dont fit together
Ok, I don't understand this then. My memory is that when the segfault
happened, s->mb_y == 1, and src_y pointed to an unmapped page (with
the following page being the start of the image buffer).
When it was called with s->mb_y ==1, I had assumed that src_y pointed
to the start of line 1 in the frame. Is that not correct?
Could you explain why you think that src_y is pointing to the start of
line 16 in the frame? (which I assume is the same as line 16 in the
image buffer?).
Are you saying that the routine is never called with src_y pointing to
the start of the image buffer?
Just to make sure we're all on the same page: I'm assuming that with
interlaced video there are 2 fields to each frame, one odd field, and
one even field. The odd field is comprised of lines 1, 3, 5, ... in
the frame, and the even field is comprised of lines 0, 2, 4, 6, ... in
the frame.
The frame is laid out in the image buffer with the first pixel of line
0 in the frame being in the first byte in the image buffer. In
particular, accessing memory before the start of line 0 is accessing
memory outside the image buffer.
I'm assuming that 'mb' stands for 'motion block', and that 's->mb_y'
is the line number of the top line in the motion block (i.e. the line
closest to the start of the image buffer).
Is all that correct?
Note that I don't understand the code; It may be that xchg_mb_border()
is never supposed to be called with src_y pointing near the start of
the image buffer? If so, the bug is elsewhere and my change is just
papering over the problem.
______________________________________________________
FFmpeg issue tracker <[EMAIL PROTECTED]>
<https://roundup.mplayerhq.hu/roundup/ffmpeg/issue427>
______________________________________________________
