On 06.07.2015 02:40, Michael Niedermayer wrote: > On Sun, Jul 05, 2015 at 09:11:44PM +0200, Andreas Cadhalpun wrote: >> Can you explain how elements can be too larger to fit? > > emulated_edge_mc() writes a block of width x height,
More precisely that's block_w x block_h. > if stride < width this will not work as intended Then an assert for stride > block_w might make sense in emulated_edge_mc, but not in add_yblock. > iam quite unsure if this is the intended thing for the assert to > check, i hthik there was more code that possibly was fixed I think the assert is a historic leftover: Before commit cc884a35 src_stride > 7*MB_SIZE was necessary, because the blocks were interleaved in the tmp buffer and the last block was added with an offset of 6*MB_SIZE. It was changed for src_stride <= 7*MB_SIZE to write the blocks sequentially, hence the larger tmp_stride. (A comment about this in the code would have been nice.) After that I think the assert was only necessary to make sure that the buffer remained large enough. Since commit bd2b6b33 s->scratchbuf is used as tmp buffer. As part of commit 86e107a7 the minimal scratchbuf size was increased to 256*7*MB_SIZE, which is enough for any src_stride <= 7*MB_SIZE. So I think removing this assert is the correct way forward. However, there are still some things in this code which are unclear for me: * Where does the 5 in 'src_stride > 2*MB_SIZE + 5' come from? Shouldn't that have been HTAPS_MAX-1, because that is added to block_h, when calling emulated_edge_mc? * Why the factor 2 in 'src_stride > 2*MB_SIZE + 5'? Before commit cc884a35 the buffer size was 'src_stride*(b_h+5)' and b_h is at maximum MB_SIZE, not 2*MB_SIZE. * Why is tmp_step based on MB_SIZE and not (MB_SIZE + HTAPS_MAX-1)? This 'HTAPS_MAX-1' is added to b_w/b_h when calling emulated_edge_mc. Maybe you can enlighten me. Best regards, Andreas _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
