[Ffmpeg-cvslog] r6231 - trunk/libavcodec/vp56.c

[Aurelien Jacobs]

On Tue, 12 Sep 2006 16:31:50 +0200
Luca Barbato <lu_zero at gentoo.org> wrote:

> Aurelien Jacobs wrote:
> > On Tue, 12 Sep 2006 09:42:26 +0200
> > Luca Barbato <lu_zero at gentoo.org> wrote:
> > 
> >> Guillaume POIRIER wrote:
> >>> Hi,
> >>>
> >>> On 9/12/06, aurel <subversion at mplayerhq.hu> wrote:
> >>>
> >>>
> >>>> don't use dsp.put_pixels_tab[0][0] with unaligned ptr (fix artifacts
> >>>> on altivec)
> >>> Isn't there a way to make sure the arrays passed to put_pixelsXY are
> >>> aligned?
> >>> Even though the MMX version of put_pixel doesn't care, it would still
> >>> be faster...
> >>>
> >>> As a side note, I imagine this has been discussed in another thread,
> >>> but it's not so easy to find where because there's no link to it in
> >>> the commit msg. :-P
> >>>
> >>> Guillaume
> >> The problem is the stride that isn't 16 multiple
> > 
> > I don't think so.
> > stride here is the linesize field from the AVFrame so I expect it to be
> > 16 multiple. Note that this stride can then be negated. Could that be
> > the problem ?
> > 
> >> put_pixel should handle unaligned load just fine.
> > 
> > Well, the src pointer is unaligned and we can't change this as it points
> > to a random pixel in the reference frame.
> > I thought that's what caused trouble with altivec isn't it ?
> > 
> 
> void put_pixels16_altivec(uint8_t *block, const uint8_t *pixels, int
> line_size, int h)
> 
> block must be aligned, pixel can be unaligned, line_size has to be a
> multiple of 16, h can be anything.

Ok. It seems that block was not properly aligned due to the use of
av_realloc. Could you please try the attached patch against r6213 ?

Aurel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vp_align.diff
Type: text/x-diff
Size: 695 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-cvslog/attachments/20060912/b863c512/attachment.diff>