[FFmpeg-devel] [PATCH] VC-1/WMV: vc1 overlap filter asm, MMX/SSE2

Kostya kostya.shishkov
Tue Oct 27 18:40:59 CET 2009


On Tue, Oct 27, 2009 at 06:32:03PM +0100, Michael Niedermayer wrote:
> On Tue, Oct 27, 2009 at 06:51:47PM +0200, Kostya wrote:
> > On Tue, Oct 27, 2009 at 05:25:32PM +0100, Michael Niedermayer wrote:
> > > On Tue, Jun 16, 2009 at 04:11:19PM -0700, Jason Garrett-Glaser wrote:
> > > > Since the patch uses 8x4/4x8 transpose macros, the macros are moved
> > > > into x86util.asm for all of the asm files to use (so it doesn't have
> > > > to be duplicated).  Since this requires %including x86util in the
> > > > deblock code, I had to rename SBUTTERFLY to SBUTTERFLY2 to avoid
> > > > namespace collisions.
> > > 
> > > renaming and moving should be seperate commits from functional changes
> > > except that, if things are tested, all ok
> > > 
> > > 
> > > > 
> > > > x86_64 overlap_h code is not 100% guaranteed to work; it seems to be
> > > > fine (it only differs in calling convention from x86_32), 
> > > 
> > > > but every
> > > > x86_64 machine I've tested on gives a different md5sum on every run of
> > > > ffmpeg regardless of whether it's patched or not (at least on my
> > > > samples with overlap filter on).  This is likely a separate bug,
> > > > probably related to the hordes of valgrind errors when decoding wmv3.
> > > 
> > > if the problem still exists ... kostya, wmv3 does not produce deterministic
> > > output?
> > 
> > IIRC, somebody mentioned qpel MC code accessing uninitialized data as
> > the source of that and it was fixed.
> > 
> > I've tested - the same sample on x86, ARM926EJ-S and PowerPC gives the same
> > CRC on consequest runs too, so it should be fine.
> 
> great
> that also means this patch can be tested for not changing the output

I'll do that tomorrow evening if there are no volunteers to do it.
 
> [...]
> -- 
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB



More information about the ffmpeg-devel mailing list