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

[Chris Stones]

>
>
> 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
>

I noticed that the b_w==1 was being generated in add_yblock() line 2450.
when encoding/deocoding plane 1.

Also, this this function caught and corrected other bad b_w, block_w, and w
values and corrected them.
So this is where i added the code to avoid b_w==1.
in the case (src_x + b_w > w), and (b_w = w - src_x;) == 1;
I reduced src_x and increaced b_w to cover the same area, mmaking its size 4
bytes plane 0, and 2 bytes plane 1/2 ( 4x4 pixels i belive)

The encoding / decoding then ran without error, but introduced artifacts.
On re-examining my origonal solution ( to use mc_block )
I noticed the artifacts were present there too, identicle, and were not
being introduced by my latest attempt.

The bug seems to be deeper than i had imagined, and was not just an
overlooked use case.

I will keep trying, but im new to the theory behind it all, and the code is
un-documented.

As for padding out the video resolution in the known problem cases, I have
already managed that.
But i hate working around faults, they are bound to come back to haunt me at
some point in the future.

"Snow - A video codec that can handle arbitary even video resolutions except
for 74 / 842, and and maybe one or two more i havent found yet"
just doesnt sit well with me.

Like i said, I will keep trying, but im a novice, i wouldnt hold my breath.

Am i correct in thinking that the snow codec development has ground to a
hault ?
The last commit was a few years ago I believe.

Anyways... Thanks... Every prod, poke and nod in the right direction brings
me that little bit closer in my tinkering!!!