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

[Michael Niedermayer]

On Tue, Jul 28, 2009 at 09:52:57PM +0100, Chris Stones wrote:
> >
> >
> > 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.

there is no point in internally supporting arbitrary resolutions, mpeg also
doesnt work on 7x3 macro blocks at the bottom right when the 16x16 block there
is truncated by thw width/height.
Theres always a full MB or none at all, similarly theres no point in snow
for such things, its a lot simpler to pad the internal buffers than to support
a few dozen more odd block sizes for MC


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

well, you are working on it now and iam awnsering your questions, that isnt
compatible with halted development so lets say it has slowed down more than
i would have wished ... simply too few people who understand the stuff AND
are have the motivation to work on it.
(we do have motivated people and we do have people who understand the stuff
 but noone who is in both these sets)

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

If you really think that XML is the answer, then you definitly missunderstood
the question -- Attila Kinali
-------------- 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/20090729/9441fc19/attachment.pgp>