Hi On Tue, Jan 30, 2007 at 07:36:46PM +0100, Reimar D?ffinger wrote: > Hello, > attached patch provide some LZO decoding speeding if either the compiler > has a builtin memcpy for fixed-size copies or the architecture can do > unaligned load/stores. > Problem is, I don't know how to properly detect either one. > Any ideas? Or should I just commit attached patch which assumes that a > memcpy builtin is used? Having a UNALIGNED_LOADSTORE or similar define > available would be nice for the stuff in intreadwrite.h, too, I guess > (though there you can at least use the unaligned_16 for gnu compilers, > that would slow things down in this case if unaligned loads/stores are > not supported though). assuming that memcpy(a,b,2 or 4) is inlined is reasonable, so always using that seems like the obvious solution, alternativly you could add AV_CP16/32 to intreadwrite.h add a check to configure which tests if unaligned stored and unaligned loads are fast and depending on the result make AV_CP* either use unaligned_* or bytewise btw do you have a file (url on mphq?) which uses lzo for testing ... ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The misfortune of the wise is better than the prosperity of the fool. -- Epicurus -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070131/4977ef95/attachment.pgp>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4