[FFmpeg-devel] [PATCH] Issue1247 - libavcodec/snow.c:2357: pred_block: Assertion `b_w>1 && b_h>1' failed.

[Michael Niedermayer]

On Fri, Jul 17, 2009 at 10:16:52PM +0100, Chris Stones wrote:
> On Thu, Jul 16, 2009 at 1:40 AM, Michael Niedermayer <michaelni at gmx.at>wrote:
> 
> >
> > It might be better to pad the buffers to avoid such sizes
> >
> 
> 
> update on my playing with snow, and the resolution 74.
> 
> The assertion:
>   ffmpeg: libavcodec/snow.c:2357: pred_block: Assertion `b_w>1 && b_h>1'
> failed.
>     in function pred_block. both b_w and b_h passed as parameters, and not
> written to.
> 
>     pred_block called in function add_yblock, but not before b_w is
> truncated at line 2449:
>         }else if(src_x + b_w > w){
>         b_w = w - src_x;
> 
>     add_yblock function called by function predict_slice_buffered on line
> 2616.
> 
>       for(mb_x=0; mb_x<=mb_w; mb_x++){
>         add_yblock(s, 1, sb, old_buffer, dst8, obmc,
>                      block_w*mb_x - block_w/2,        // this is parameter
> src_x
>                      block_w*mb_y - block_w/2,
>                      block_w, block_w,            // this is parameter b_w
> and bh,
>                      w, h,                // this is parameter w
>                      w, ref_stride, obmc_stride,
>                      mb_x - 1, mb_y - 1,
>                      add, 0, plane_index);
> 
>     remember... b_w == 1 will cause the assertion to fail.
>     and if(src_x + b_w > w) then b_w = w - src_x; ( line 2449 in add_yblock
> )
> 
>     block_w is plane_index ? block_size/2 : block_size;
>     block_size is MB_SIZE >> s->block_max_depth  // (block_max_depth 0, snow
> doesnt support CODEC_FLAG_4MV ? )
>     MB_SIZE is 16 ()  // #define LOG2_MB_SIZE 4 \n #define MB_SIZE
> (1<<LOG2_MB_SIZE)
> 
>     So.. my thinking is as follows..
>     when encoding/decoding chroma ( plane_index == 1) then block_w == 8.
> 
>     when the for loop above gets to m_x == 5, then
>     src_x = block_w*mb_x - block_w/2  // == 36
>     and int w = p->width; ( plane width, which i believe will be 74/2 ( x
> resolution / 2 for chroma ( plane_index 1 ))
> 
>    which means, we have no tripped the afore mentioned truncation of b_w.
>    src_x(36) + block_w(8) > w(37)
> 
>    the truncation..now puts b_w = w - src_x  ( 1 ).
> 
>    Please correct me if im wrong, but it looks like a mathematical fact,
> that with a resolution of 74xanything
>    will trip this assertion.
> 
>    It seems like a mathematical fact, that b_w==1 will occur ?????

we already know that the assertion can trip in this case, the goal now
is to chnage the source so such silly block sizes do not occur.


> 
>    I dont see anywhere i can *padd the buffers*

you can specify 76 instead of 74 that padded the buffer, now do it inside
the decoder when the width or height is not a muliple of 4

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090728/6f5c7e13/attachment.pgp>