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
[...]
> So src_y is now &buffer[-1079]; I.e. it now points before the start of
> the buffer. (note that it also does this when the video is
> progressive, so it's not bad in itself).
it does point before "buffer" but not before the allocated space.
[...]
______________________________________________________
FFmpeg issue tracker <[EMAIL PROTECTED]>
<https://roundup.mplayerhq.hu/roundup/ffmpeg/issue427>
______________________________________________________
