Discussion:
[PATCH] Coremake support
(too old to reply)
Steve Lhomme
2007-05-14 08:37:19 UTC
Permalink
Hi everyone,

Here is a patch to support the coremake "meta-makefile system". Like
bakefile or cmake, coremake can generate makefiles and project files for
various IDEs. It was developped by CoreCodec to build CorePlayer
(formerly known as TCPMP), CoreAVC and all other products on all the
platforms we support (windows, windows CE, symbian, palm, OS X, linux,
Sun). It is also used in DrDivX/DrFFMPEG and thus supports Qt4 special
build commands (tested on windows and OS X).

The goal here is not to replace the current makefiles that do more than
coremake is capable of doing now (install files after make, out of tree
builds). But to give a wider choice of development environment when
possible. It can also offer features not found in the current makefile
like precompiled headers (used in DrFFMPEG with a good speedup of
compilation).

The current configuration that should work out of the box with FFMPEG are:
- gcc_win32 (make + mingw/cygwin)
- gcc_linux (Make + gcc on linux)
- gcc_linux_x64 (make + gcc x64 on linux)
- gcc_osx_ppc (make + gcc PPC on OS X)
- gcc_osx_x86 (make + gcc x86 on OS X)
- xcode (xcode native project files)

Other targets may be supported by FFMPEG with little changes in the code
(for ex some Symbian flavors might work already, OS X universal builds
will work if both PPC and x86 can be activated by the configure script).
All the possible outputs correspond to all the .build files the
"coremake" directory (imported from the official SVN).

The temporary object files are put in the /build folder and the result
output files are put in /release.

All libraries are created as "DLL". If CONFIG_STATIC is found in
config.h then these "DLL" are turned into "LIB".

I tested it successfully with MinGW with this script:
./configure --enable-memalign-hack --disable-shared --coremake=gcc_win32

Any comments/suggestion is welcome. We're still working a lot on
coremake. There's still plenty of stuff to do.

Steve
Måns Rullgård
2007-05-14 08:51:57 UTC
Permalink
Post by Steve Lhomme
Hi everyone,
Here is a patch to support the coremake "meta-makefile system". Like
bakefile or cmake, coremake can generate makefiles and project files for
various IDEs. It was developped by CoreCodec to build CorePlayer
(formerly known as TCPMP), CoreAVC and all other products on all the
platforms we support (windows, windows CE, symbian, palm, OS X, linux,
Sun). It is also used in DrDivX/DrFFMPEG and thus supports Qt4 special
build commands (tested on windows and OS X).
The goal here is not to replace the current makefiles that do more than
coremake is capable of doing now (install files after make, out of tree
builds). But to give a wider choice of development environment when
possible. It can also offer features not found in the current makefile
like precompiled headers (used in DrFFMPEG with a good speedup of
compilation).
All this addition would buy us is increased support and maintenance burden.
The existing makefiles are perfectly adequate for all supported targets.
--
Måns Rullgård
***@mansr.com
Reimar Doeffinger
2007-05-14 08:57:29 UTC
Permalink
Hello,
not a good start, since corecodec.org is down I can't even look for
documentation for it.
Also it duplicates most of the stuff in the Makefiles which is a bad
thing in itself, but also a very big problem since the build system is
updated at a rate that even MPlayer can hardly keep up with.
Unless Diego or Mans intend to use or at least regularly test this, it
IMO is doomed to be constantly outdated and broken and thus there is not
much point to include it, it will only create the illusion of supporting
something we actually don't support :-(

Greetings,
Reimar Doeffinger
Steve Lhomme
2007-05-14 09:11:36 UTC
Permalink
Post by Reimar Doeffinger
Hello,
not a good start, since corecodec.org is down I can't even look for
documentation for it.
Yeah, that's a chronic problem. That's why the SVN is on matroska.org.

There's no documentation on coremake right now. There's only one C file
and script files for which the syntax is easy to understand (it's C
inspired).
Post by Reimar Doeffinger
Also it duplicates most of the stuff in the Makefiles which is a bad
thing in itself, but also a very big problem since the build system is
updated at a rate that even MPlayer can hardly keep up with.
Unless Diego or Mans intend to use or at least regularly test this, it
IMO is doomed to be constantly outdated and broken and thus there is not
much point to include it, it will only create the illusion of supporting
something we actually don't support :-(
In the future we plan to support FFMPEG in BetaPlayer (the open source
version of CorePlayer) so we will surely want this thing up to date. And
including support for platforms where FFMPEG is not used (AFAIK) like
Symbian and maybe PalmOS. While PalmOS could do with tweakings of the
current makefile, Symbian will not work. And most of you can hardly test
it since the dev tools are Windows only.

We could also be constructive and add what's missing in Coremake to do
all that the current makefiles do. Coremake is BSD licensed, and
everybody is welcome to contribute :)

Steve
Luca Barbato
2007-05-14 10:24:57 UTC
Permalink
Post by Steve Lhomme
Post by Reimar Doeffinger
Hello,
not a good start, since corecodec.org is down I can't even look for
documentation for it.
Yeah, that's a chronic problem. That's why the SVN is on matroska.org.
There's no documentation on coremake right now. There's only one C file
and script files for which the syntax is easy to understand (it's C
inspired).
Let me sum it up:

- it is a cmake alternative
- it has a saner syntax
- it is written in C

Cons
- doesn't have documentation
- adds not much for the people with a working make/sh

Pros
- you'll take the burden to keep it up to date
- new IDE users would feel better with their native bloatconf
- you'd like to extend it to suit ffmpeg needs and other needs beside
yours specific

That said if the documentation appears and having support for it won't
require effort for the other developers beside reply to your question
when we do some esoteric changes to the makefiles, I think is reasonable
give it a chance, given we are trying to move to git maybe won't hurt if
you maintain it on a separate branch/your local repo and let others pull
from you to check it.

lu
--
Luca Barbato

Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
Michael Niedermayer
2007-05-14 10:26:21 UTC
Permalink
Hi
Post by Luca Barbato
Post by Steve Lhomme
Post by Reimar Doeffinger
Hello,
not a good start, since corecodec.org is down I can't even look for
documentation for it.
Yeah, that's a chronic problem. That's why the SVN is on matroska.org.
There's no documentation on coremake right now. There's only one C file
and script files for which the syntax is easy to understand (it's C
inspired).
- it is a cmake alternative
- it has a saner syntax
- it is written in C
Cons
- doesn't have documentation
- adds not much for the people with a working make/sh
Pros
- you'll take the burden to keep it up to date
- new IDE users would feel better with their native bloatconf
- you'd like to extend it to suit ffmpeg needs and other needs beside
yours specific
That said if the documentation appears and having support for it won't
require effort for the other developers beside reply to your question
when we do some esoteric changes to the makefiles, I think is reasonable
give it a chance, given we are trying to move to git maybe won't hurt if
you maintain it on a separate branch/your local repo and let others pull
Post by Steve Lhomme
from you to check it.
iam not against a branch/repo with that make alternative but iam against
having 2 seperate make systems in main ffmpeg

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

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus
Steve Lhomme
2007-05-14 11:33:02 UTC
Permalink
Post by Michael Niedermayer
Hi
Post by Luca Barbato
Post by Steve Lhomme
Post by Reimar Doeffinger
Hello,
not a good start, since corecodec.org is down I can't even look for
documentation for it.
Yeah, that's a chronic problem. That's why the SVN is on matroska.org.
There's no documentation on coremake right now. There's only one C file
and script files for which the syntax is easy to understand (it's C
inspired).
- it is a cmake alternative
- it has a saner syntax
- it is written in C
Cons
- doesn't have documentation
- adds not much for the people with a working make/sh
Pros
- you'll take the burden to keep it up to date
- new IDE users would feel better with their native bloatconf
- you'd like to extend it to suit ffmpeg needs and other needs beside
yours specific
Yes. Thanks to that coremake will also be better suited at UNIX
developpers in general. For example right now it's not possible to use
it when installed on the system (in the patch it's run from the local
dir) because it looks for the .build file in specific places. And the
goal of such a tool is to be usable in many different environment, at
least all the common ones.
Post by Michael Niedermayer
Post by Luca Barbato
That said if the documentation appears and having support for it won't
Yes, there will be some documentation. Maybe using coremake.
Post by Michael Niedermayer
Post by Luca Barbato
require effort for the other developers beside reply to your question
when we do some esoteric changes to the makefiles, I think is reasonable
give it a chance, given we are trying to move to git maybe won't hurt if
you maintain it on a separate branch/your local repo and let others pull
Post by Steve Lhomme
from you to check it.
iam not against a branch/repo with that make alternative but iam against
having 2 seperate make systems in main ffmpeg
Yes, a branch would be nice and more logical. I assume that git cannot
use svn:externals so I'll have to maintain 2 copies in parallel. But
it's not a big issue.

Steve
Luca Barbato
2007-05-14 14:21:33 UTC
Permalink
Post by Steve Lhomme
Yes, a branch would be nice and more logical. I assume that git cannot
use svn:externals so I'll have to maintain 2 copies in parallel. But
it's not a big issue.
create a new branch and edit the config so it will fast forward the
origin/master changes there too (it doesn't work as the extern but
should be ok for your needs)

lu
--
Luca Barbato

Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
Diego Biurrun
2007-05-14 09:06:51 UTC
Permalink
Post by Steve Lhomme
Here is a patch to support the coremake "meta-makefile system". Like
bakefile or cmake, coremake can generate makefiles and project files for
various IDEs. It was developped by CoreCodec to build CorePlayer
(formerly known as TCPMP), CoreAVC and all other products on all the
platforms we support (windows, windows CE, symbian, palm, OS X, linux,
Sun). It is also used in DrDivX/DrFFMPEG and thus supports Qt4 special
build commands (tested on windows and OS X).
Why? Reinventing the wheel due to NIH syndrome?
Post by Steve Lhomme
The goal here is not to replace the current makefiles that do more than
coremake is capable of doing now (install files after make, out of tree
builds). But to give a wider choice of development environment when
possible. It can also offer features not found in the current makefile
like precompiled headers (used in DrFFMPEG with a good speedup of
compilation).
.. and this cannot be done through hacking the Makefiles? ..
Post by Steve Lhomme
Any comments/suggestion is welcome. We're still working a lot on
coremake. There's still plenty of stuff to do.
Since this basically duplicates the Makefiles, it's unacceptable in its
current form. Furthermore, I fail to see advantages...

Was your intention getting this patch applied?

Diego
Steve Lhomme
2007-05-14 09:32:19 UTC
Permalink
Post by Diego Biurrun
Post by Steve Lhomme
Here is a patch to support the coremake "meta-makefile system". Like
bakefile or cmake, coremake can generate makefiles and project files for
various IDEs. It was developped by CoreCodec to build CorePlayer
(formerly known as TCPMP), CoreAVC and all other products on all the
platforms we support (windows, windows CE, symbian, palm, OS X, linux,
Sun). It is also used in DrDivX/DrFFMPEG and thus supports Qt4 special
build commands (tested on windows and OS X).
Why? Reinventing the wheel due to NIH syndrome?
Neither bakefile or cmake handle assembler files correctly. bakefile
just added incomplete VStudio2005 support a couple of weeks ago, and
DrDivX has been using extensively VStudio2005 for a long time.

Picard created coremake for his own purpose to manage all the platforms
we support. Then we realised it could be used more widely and is quite
elegant compared to other solutions (no script runtime needed, only a C
compiler). And the syntax is more readable than bakefile (I only had a
quick look at cmake but it didn't look so good either).
Post by Diego Biurrun
Post by Steve Lhomme
The goal here is not to replace the current makefiles that do more than
coremake is capable of doing now (install files after make, out of tree
builds). But to give a wider choice of development environment when
possible. It can also offer features not found in the current makefile
like precompiled headers (used in DrFFMPEG with a good speedup of
compilation).
.. and this cannot be done through hacking the Makefiles? ..
For that yes.
Post by Diego Biurrun
Post by Steve Lhomme
Any comments/suggestion is welcome. We're still working a lot on
coremake. There's still plenty of stuff to do.
Since this basically duplicates the Makefiles, it's unacceptable in its
current form. Furthermore, I fail to see advantages...
I guess nobody develops FFMPEG with a modern IDE. But it could very well
become true if you can generate IDE projects instead of just relying on
makefiles. XCode support is already a good bonus for all OS X devs
(although it would be even better if it could create universal binaries
with just one run of configure, even CoreAVC can do that). Symbian uses
Carbide which is just a custom Eclipse version. So Eclipse support could
be added easily too (I plan to do it with Eclipse+MinGW).
Post by Diego Biurrun
Was your intention getting this patch applied?
You know, I like wasting my time ;)

Yes, I hope this can be applied someday. I didn't expect this to be
added right away.

I plan to do the same for VLC before the summer. I already started to do
it for mkvmerge and Perian (so Perian could be used on Windows Quicktime
too). The issue for such big projects is managing the various external
dependencies.

Steve
Måns Rullgård
2007-05-14 12:43:39 UTC
Permalink
Post by Steve Lhomme
Post by Diego Biurrun
Post by Steve Lhomme
Here is a patch to support the coremake "meta-makefile system". Like
bakefile or cmake, coremake can generate makefiles and project files for
various IDEs. It was developped by CoreCodec to build CorePlayer
(formerly known as TCPMP), CoreAVC and all other products on all the
platforms we support (windows, windows CE, symbian, palm, OS X, linux,
Sun). It is also used in DrDivX/DrFFMPEG and thus supports Qt4 special
build commands (tested on windows and OS X).
Why? Reinventing the wheel due to NIH syndrome?
Neither bakefile or cmake handle assembler files correctly. bakefile
FFmpeg uses GNU make, which supports everything we need perfectly.
--
Måns Rullgård
***@mansr.com
Steve Lhomme
2007-05-14 14:26:25 UTC
Permalink
Post by Måns Rullgård
Post by Steve Lhomme
Post by Diego Biurrun
Post by Steve Lhomme
Here is a patch to support the coremake "meta-makefile system". Like
bakefile or cmake, coremake can generate makefiles and project files for
various IDEs. It was developped by CoreCodec to build CorePlayer
(formerly known as TCPMP), CoreAVC and all other products on all the
platforms we support (windows, windows CE, symbian, palm, OS X, linux,
Sun). It is also used in DrDivX/DrFFMPEG and thus supports Qt4 special
build commands (tested on windows and OS X).
Why? Reinventing the wheel due to NIH syndrome?
Neither bakefile or cmake handle assembler files correctly. bakefile
FFmpeg uses GNU make, which supports everything we need perfectly.
Don't want to turn this thread into a rhetoric contest. But who do you
call "we" ? Is it the FFMPEG devs that have SVN access ? FFMPEG devs who
use the FFMPEG libraries ? FFMPEG users ? potential FFMPEG devs that
would like to work with something better than this perfect solution you
like ?

Steve
Måns Rullgård
2007-05-14 14:36:01 UTC
Permalink
Post by Steve Lhomme
Post by Måns Rullgård
Post by Steve Lhomme
Post by Diego Biurrun
Post by Steve Lhomme
Here is a patch to support the coremake "meta-makefile system". Like
bakefile or cmake, coremake can generate makefiles and project files for
various IDEs. It was developped by CoreCodec to build CorePlayer
(formerly known as TCPMP), CoreAVC and all other products on all the
platforms we support (windows, windows CE, symbian, palm, OS X, linux,
Sun). It is also used in DrDivX/DrFFMPEG and thus supports Qt4 special
build commands (tested on windows and OS X).
Why? Reinventing the wheel due to NIH syndrome?
Neither bakefile or cmake handle assembler files correctly. bakefile
FFmpeg uses GNU make, which supports everything we need perfectly.
Don't want to turn this thread into a rhetoric contest. But who do you
call "we" ? Is it the FFMPEG devs that have SVN access ?
Pretty much.
Post by Steve Lhomme
FFMPEG devs who use the FFMPEG libraries ? FFMPEG users ?
They seem to be quite happy with the current makefiles. No problem we've
encountered so far has been unsolvable with configure/make.
Post by Steve Lhomme
potential FFMPEG devs that
would like to work with something better than this perfect solution you
like ?
If they can't cope with running make, they surely won't be able to contribute
anything useful.
--
Måns Rullgård
***@mansr.com
Ronald S. Bultje
2007-05-14 15:07:31 UTC
Permalink
Hi,
Post by Måns Rullgård
Post by Steve Lhomme
FFMPEG devs who use the FFMPEG libraries ? FFMPEG users ?
They seem to be quite happy with the current makefiles. No problem
we've
encountered so far has been unsolvable with configure/make.
Now wait a minute, don't make yourself believe things that are not true.

Your configure/make thing is a hell to work with. Since years, I've
maintained my own build system for ffmpeg/lav[cfu] which is based
around automake/autoconf, and I will continue doing that until GNOME
stops using auto*. Whatever GNOME moves to, I'll port this patch to.
This is how projects that I've set up or my private projects use
ffmpeg/lav[ufc], and this is how I contribute patches to ffmpeg. Your
bash script or whatever-it-is may work for building peanuts or
mplayer, but is unworkable otherwise. You'll also notice that other
larger software projects, e.g. vlc and xine, integrate ffmpeg into
their own build system (which is auto*-based); they don't actually
use the configure/make trick that you use.

I call this hell because it's a large and laborous task, which isn't
exactly interesting. However, it's necessary. Please stop making
yourself believe ffmpeg's build system is elegant or that the larger
projects using it like it or even use it. Not that I think this
CoreMake thing is any better, or that I have the illusion that ffmpeg
will ever accept using auto*, I'm not that stupid. I submitted the
patch and accept it being rejected by principle. For now. :-).

Ronald
Diego 'Flameeyes' Pettenò
2007-05-14 15:12:33 UTC
Permalink
On Mon, 14 May 2007 11:07:31 -0400
Post by Ronald S. Bultje
You'll also notice that other
larger software projects, e.g. vlc and xine, integrate ffmpeg into
their own build system (which is auto*-based); they don't actually
use the configure/make trick that you use.
And I find that unworkable so I've started NOT doing that anymore for
xine-lib-1.2 series and integrated FFmpeg's own build system into an
autoconf/automake shell.

It's far from difficult to handle, the most difficult thing was to have
make dist working, and I've fixed that just by having a listing of the
files in the svn export.

Matt Messier was also able to get Mac OS X Universal Binary builds
working without having to touch a single file in FFmpeg.
--
Diego "Flameeyes" Pettenò
http://farragut.flameeyes.is-a-geek.org/
Måns Rullgård
2007-05-14 15:28:44 UTC
Permalink
Post by Ronald S. Bultje
Hi,
Post by Måns Rullgård
Post by Steve Lhomme
FFMPEG devs who use the FFMPEG libraries ? FFMPEG users ?
They seem to be quite happy with the current makefiles. No problem
we've
encountered so far has been unsolvable with configure/make.
Now wait a minute, don't make yourself believe things that are not true.
Your configure/make thing is a hell to work with. Since years, I've
maintained my own build system for ffmpeg/lav[cfu] which is based
around automake/autoconf, and I will continue doing that until GNOME
ROTFL.
Post by Ronald S. Bultje
stops using auto*. Whatever GNOME moves to, I'll port this patch to.
LMAO.
Post by Ronald S. Bultje
This is how projects that I've set up or my private projects use
ffmpeg/lav[ufc], and this is how I contribute patches to ffmpeg. Your
bash script or whatever-it-is may work for building peanuts or
mplayer, but is unworkable otherwise. You'll also notice that other
Huh? The FFmpeg configure script is suitable for building FFmpeg. It's
not meant to be used for anything else.
--
Måns Rullgård
***@mansr.com
Reimar Döffinger
2007-05-14 15:36:50 UTC
Permalink
Hello,
On Mon, May 14, 2007 at 11:07:31AM -0400, Ronald S. Bultje wrote:
[...]
Post by Ronald S. Bultje
Your
bash script or whatever-it-is may work for building peanuts or
mplayer, but is unworkable otherwise.
Why?
Post by Ronald S. Bultje
You'll also notice that other
larger software projects, e.g. vlc and xine, integrate ffmpeg into
their own build system (which is auto*-based); they don't actually
use the configure/make trick that you use.
Are you sure they wouldn't still do that even when we were using auto*?
If you wanted to use ffmpeg configure, whatever it is based on, you'd
have to include the whole ffmpeg directory instead of only libavutil/
libavcodec/libavformat.
You'd also have to convert your configure options into ffmpeg ones.

[...]
Post by Ronald S. Bultje
CoreMake thing is any better, or that I have the illusion that ffmpeg
will ever accept using auto*, I'm not that stupid. I submitted the
patch and accept it being rejected by principle. For now. :-).
With good reason, auto* is hard to read and almost impossible to debug
and fix - to locate the problem you first have to check the really
unreadable shell script, then sort out the parts that were not
auto-generated to search for them in the ac file and you still have to
handle the horrible mixture of self-hacked checks in shell script and
other stuff.
If it would at least produce shell scripts that are correctly indented
instead of just randomly...

Greetings,
Reimar Döffinger
Michel Bardiaux
2007-05-14 15:44:10 UTC
Permalink
Reimar Döffinger wrote:
[snip]
Post by Reimar Döffinger
With good reason, auto* is hard to read and almost impossible to debug
and fix - to locate the problem you first have to check the really
unreadable shell script, then sort out the parts that were not
auto-generated to search for them in the ac file and you still have to
handle the horrible mixture of self-hacked checks in shell script and
other stuff.
If it would at least produce shell scripts that are correctly indented
instead of just randomly...
FWIW my own pet peeve against autostuff is the built-in tendency to
require the bleeding-edge latest release of all the autotools, when its
not of umpteen build tools.

Which doesnt mean Reimer isnt right, only that autos!@#$% manages to
make life difficult even for those who *dont* dig into the autoscripts.
--
Michel Bardiaux
R&D Director
T +32 [0] 2 790 29 41
F +32 [0] 2 790 29 02
E mailto:***@mediaxim.be

Mediaxim NV/SA
Vorstlaan 191 Boulevard du Souverain
Brussel 1160 Bruxelles
http://www.mediaxim.com/
Luca Barbato
2007-05-14 16:02:06 UTC
Permalink
Post by Reimar Döffinger
With good reason, auto* is hard to read and almost impossible to debug
and fix -
Usually because who wrote them doesn't have 1/2 clue about how to use
them properly...

In the perfect world everybody provides its little .m4 script if
requires some exotic check and the others would just offer a pkg-config
file that is easy to check using the pkg-config provided generic .m4

In this already perfect world the autostuff won't change too much interface.

Obviously that isn't the case, you have lots of bad hacks, programs
using different version of autostuff at the same time and lot of people
simply adding bad hacks over bad hacks just to get the work done...

That said autotools are far from be the worst senseless thing I happened
to touch (hi scons) or the one with more kool-aid builtin (hi CMake).

As usual things improve and you won't get hurt in checking if the mess
is cleared from time to time.

lu
--
Luca Barbato

Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
Steve Lhomme
2007-05-14 16:48:09 UTC
Permalink
Post by Ronald S. Bultje
Hi,
Post by Måns Rullgård
Post by Steve Lhomme
FFMPEG devs who use the FFMPEG libraries ? FFMPEG users ?
They seem to be quite happy with the current makefiles. No problem
we've
encountered so far has been unsolvable with configure/make.
Now wait a minute, don't make yourself believe things that are not true.
Your configure/make thing is a hell to work with. Since years, I've
maintained my own build system for ffmpeg/lav[cfu] which is based
around automake/autoconf, and I will continue doing that until GNOME
stops using auto*. Whatever GNOME moves to, I'll port this patch to.
For the record, coremake can generate Makefile.am files. That's how it
supports kdevelop.

So if you run ./configure --coremake=kdevelop you'll end up with files
ready to pass into automake and matching the result of the configure
script. That comes free with the coremake patch ;)

Steve
Diego Biurrun
2007-05-14 20:52:44 UTC
Permalink
[...]
Your mailer breaks threading, please fix it.

Diego
Diego Biurrun
2007-05-14 20:57:36 UTC
Permalink
Post by Ronald S. Bultje
Post by Måns Rullgård
Post by Steve Lhomme
FFMPEG devs who use the FFMPEG libraries ? FFMPEG users ?
They seem to be quite happy with the current makefiles. No problem
we've encountered so far has been unsolvable with configure/make.
Now wait a minute, don't make yourself believe things that are not true.
Your configure/make thing is a hell to work with. Since years, I've
maintained my own build system for ffmpeg/lav[cfu] which is based
around automake/autoconf, and I will continue doing that until GNOME
stops using auto*. Whatever GNOME moves to, I'll port this patch to.
This is how projects that I've set up or my private projects use
ffmpeg/lav[ufc], and this is how I contribute patches to ffmpeg. Your
bash script or whatever-it-is
POSIX shell, nothing bash-specific in there.
Post by Ronald S. Bultje
may work for building peanuts or mplayer, but is unworkable otherwise.
That surely is the first time somebody accuses MPlayer of being small.
Might be that it is compared to vlc/xine/gstreamer...
Post by Ronald S. Bultje
I call this hell because it's a large and laborous task, which isn't
exactly interesting. However, it's necessary. Please stop making
yourself believe ffmpeg's build system is elegant or that the larger
projects using it like it or even use it. Not that I think this
CoreMake thing is any better, or that I have the illusion that ffmpeg
will ever accept using auto*, I'm not that stupid. I submitted the
patch and accept it being rejected by principle. For now. :-).
Not for now, forever.

You may have noticed that KDE dropped auto* a short while ago. You may
not like it, but it's clearly a trend. auto* is on the way out into
obsolescence.

Diego
Luca Barbato
2007-05-14 22:03:16 UTC
Permalink
Post by Diego Biurrun
You may have noticed that KDE dropped auto* a short while ago. You may
not like it, but it's clearly a trend. auto* is on the way out into
obsolescence.
given certain alternatives (and why they got in) I'd rather keep
autotools...

lu
--
Luca Barbato

Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
Ronald S. Bultje
2007-05-14 15:18:25 UTC
Permalink
Hi Diego,
Post by Diego 'Flameeyes' Pettenò
On Mon, 14 May 2007 11:07:31 -0400
Post by Ronald S. Bultje
You'll also notice that other
larger software projects, e.g. vlc and xine, integrate ffmpeg into
their own build system (which is auto*-based); they don't actually
use the configure/make trick that you use.
And I find that unworkable so I've started NOT doing that anymore for
xine-lib-1.2 series and integrated FFmpeg's own build system into an
autoconf/automake shell.
May I be free enough to reword this as "just by mere burden of work,
I decided to go with basing my new build system on the ffmpeg make
system, but I'd really just prefer them to do it in a way that is
more convenient to my purposes"? Let's not talk us versus you, let's
talk about what we'd like to have.

Ronald
Diego 'Flameeyes' Pettenò
2007-05-14 15:31:04 UTC
Permalink
On Mon, 14 May 2007 11:18:25 -0400
Post by Ronald S. Bultje
May I be free enough to reword this
No, you're not free to put words into my mouth, thank you.

I don't think FFmpeg using autoconf/automake would have made my job any
easier; rewriting the build system every time as was done before did
make it more complex, and didn't allow the same fine-grained setup as
we have now in xine-lib-1.2; I think the problem here was the first
choice to rewrite it rather than doing the right thing the first time
around: use FFmpeg's (although I suppose this might have been more
complex, I wasn't around when FFmpeg was first introduced so I'm not
sure what was used at the time).

Having FFmpeg switching to CMake (and probably coremake also counts
that way, I haven't looked it up yet to know), *that* will make my life
way harder, to the point I'd probably have to return to rewrite of the
build system to automake (just because CMake-in-automake is more than
simple chaos).

So, what do I want from FFmpeg? Hmm, I'd like they didn't skip over my
patches most of the times, but that can't be helped, can it? ;)
The build system for me is fine as it is; well it might be a bit easier
for xine if FFmpeg supported Mac OS X Universal Binary building
natively, without having to add more code to xine, but I suppose that
if I spent enough time trying to find a pleasant solution, I would have
had that already.

So the only thing I can hope for is that FFmpeg never switches to CMake
or something that messy.
--
Diego "Flameeyes" Pettenò
http://farragut.flameeyes.is-a-geek.org/
Luca Barbato
2007-05-14 15:35:04 UTC
Permalink
Post by Ronald S. Bultje
May I be free enough to reword this as "just by mere burden of work,
I decided to go with basing my new build system on the ffmpeg make
system, but I'd really just prefer them to do it in a way that is
more convenient to my purposes"? Let's not talk us versus you, let's
talk about what we'd like to have.
A good way to avoid that on the first stance? Namely coordinating
"release snapshot" across distributions/concerned parties?

lu

PS: I'm thinking about doing a snapshot along this or the next week for
gentoo, anybody willing to jump the bandwagon?
--
Luca Barbato

Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
Ronald S. Bultje
2007-05-14 16:07:54 UTC
Permalink
Hi Luca,
Post by Luca Barbato
Post by Ronald S. Bultje
May I be free enough to reword this as "just by mere burden of work,
I decided to go with basing my new build system on the ffmpeg make
system, but I'd really just prefer them to do it in a way that is
more convenient to my purposes"? Let's not talk us versus you, let's
talk about what we'd like to have.
A good way to avoid that on the first stance? Namely coordinating
"release snapshot" across distributions/concerned parties?
lu
PS: I'm thinking about doing a snapshot along this or the next week
for
gentoo, anybody willing to jump the bandwagon?
For distribution purposes (i.e. stable versions of software), I think
this is indeed a good idea. I think Fedora does something similar. By
that, it's useful for certain purposes, and it addresses important
purposes, e.g. getting security issues addressed in a single go.

However, I think it's parallel to what I'm trying to address here,
which is more addresses to making developing of software using ffmpeg
easier. Development will always try to use recent (ideally svn trunk)
versions of ffmpeg. What I'd like to have is something that
seamlessly allows me to integrate random (basically "latest") ffmpeg
snapshots into a project without too much hassle.

The reason that I wrote the auto* patch is because it allows exactly
that. Without any additional work in the source tree that I'm
integrating ffmpeg into, I can wrap it with a single line in the
projects configure.ac (check AC_CONFIG_SUBDIRS). If such a patch were
ever to be integrated upstream it would allow literally hassle-free
integration of ffmpeg into any project (Reimar, seriously, check
AC_CONFIG_SUBDIRS, it does _everything_ and is made exactly to handle
this kind of stuff). The current configure solution doesn't allow
that, because it doesn't support integration into the parent source
tree for things like make dist for tarball generation and stuff like
that.

(Please note that I'm not advocating the use of auto* here, I'm
trying to present it as something that it allowed me to do exactly
this, and I agree completely with Reimar that auto* is hard to read
(but then again, so is the current configure script...). I happen to
be reasonably failiar with auto* which allowed me to write the patch.
I'm open for any other solution that allows this kind of hassle-free
integration of ffmpeg into a source tree.)

Ronald
Luca Barbato
2007-05-14 16:23:47 UTC
Permalink
Post by Ronald S. Bultje
(Please note that I'm not advocating the use of auto* here, I'm
trying to present it as something that it allowed me to do exactly
this, and I agree completely with Reimar that auto* is hard to read
(but then again, so is the current configure script...). I happen to
be reasonably failiar with auto* which allowed me to write the patch.
I'm open for any other solution that allows this kind of hassle-free
integration of ffmpeg into a source tree.)
Since Diego did that already for xine, maybe would be possible lump
everything in an m4 + Makefile.am targets.

Notice that is a solution just for people using autotools and willing to
have ffmpeg as part of their build system.

I have some programs using autotools and ffmpeg and I live happy with
pkg-config checks and nothing else ^^

lu
--
Luca Barbato

Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
Reimar Döffinger
2007-05-14 16:29:42 UTC
Permalink
Hello,
On Mon, May 14, 2007 at 12:07:54PM -0400, Ronald S. Bultje wrote:
[...]
Post by Ronald S. Bultje
The reason that I wrote the auto* patch is because it allows exactly
that. Without any additional work in the source tree that I'm
integrating ffmpeg into, I can wrap it with a single line in the
projects configure.ac (check AC_CONFIG_SUBDIRS). If such a patch were
ever to be integrated upstream it would allow literally hassle-free
integration of ffmpeg into any project (Reimar, seriously, check
AC_CONFIG_SUBDIRS, it does _everything_ and is made exactly to handle
this kind of stuff).
I think you misunderstood at least partially. The currently problem is
setting the whole ENABLED_*, CONFIG_*, HAVE_* and TARGET_*. Some of
these can probably be mapped to autoconf default stuff, but for
everything else you'd still have to write code to set them.
Post by Ronald S. Bultje
The current configure solution doesn't allow
that, because it doesn't support integration into the parent source
tree for things like make dist for tarball generation and stuff like
that.
With the current build system you could e.g. add dist target to the
generated config.mak.
It might also be possible to find other ways to make these things
simpler by changing our configure a bit.
E.g. one thing to consider might be to split configure into separate
configures in the libav* subdirectories. Maybe that wouldn't work out,
but it might be worth a try if someone has time to waste *g*

Greetings,
Reimar Döffinger
Dominik 'Rathann' Mierzejewski
2007-05-15 13:41:17 UTC
Permalink
Post by Ronald S. Bultje
Hi Luca,
Post by Luca Barbato
Post by Ronald S. Bultje
May I be free enough to reword this as "just by mere burden of work,
I decided to go with basing my new build system on the ffmpeg make
system, but I'd really just prefer them to do it in a way that is
more convenient to my purposes"? Let's not talk us versus you, let's
talk about what we'd like to have.
A good way to avoid that on the first stance? Namely coordinating
"release snapshot" across distributions/concerned parties?
lu
PS: I'm thinking about doing a snapshot along this or the next week
for
gentoo, anybody willing to jump the bandwagon?
For distribution purposes (i.e. stable versions of software), I think
this is indeed a good idea. I think Fedora does something similar.
Fedora doesn't, because of patent issues. But there are semi-official
packages for Fedora that I maintain. But yes, I do package snapshots.

Regards,
R.
--
MPlayer developer and RPMs maintainer: http://mplayerhq.hu http://rpm.livna.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
Ronald S. Bultje
2007-05-14 17:47:52 UTC
Permalink
Hi Reimar,
Post by Reimar Döffinger
I think you misunderstood at least partially. The currently problem is
setting the whole ENABLED_*, CONFIG_*, HAVE_* and TARGET_*. Some of
these can probably be mapped to autoconf default stuff, but for
everything else you'd still have to write code to set them.
Well, so if you call AC_CONFIG_SUBDIRS, basically your configure
calls the ffmpeg configure, so ffmpeg's configure just does that for
you like it always does. Essentially (this is purely theoretical),
ffmpeg doesn't even need to be autotools-based (oh god I can see the
replies on this one coming) _as long as it implements all the
relevant make targets_ (distcheck being the most important one for
me). Like I said, I'm totally fine with adding all these make targets
to ffmpeg's build system manually, as long as it works (right now it
doesn't). IMHO it's just a lot easier to let it all be done
automatically by using auto* than doing it all manually. A quick wc -
l/-c shows that my Makefile.ams + configure.ac are currently +/- 2250
lines or 48000 bytes - how much is ffmpeg's configure + Makefile?

Anway, as per your question, you're using ffmpeg's configure, so
specifying custom arguments to ffmpeg's configure from your configure
(which calls ffmpeg's configure via the AC_CONFIG_SUBDIRS) can be
done, of course (e.g. in my projects, I always build with --disable-
ffserver, --disable-oss/sunaudio/etc., --disable-v4l, etc., b/c I
really just need lav[fcu]) and custom build vars (--prefix, --
builddir, etc.) are forwarded automatically.

Or did I misunderstand you?

Ronald
Måns Rullgård
2007-05-14 17:56:24 UTC
Permalink
Post by Ronald S. Bultje
Hi Reimar,
Post by Reimar Döffinger
I think you misunderstood at least partially. The currently problem is
setting the whole ENABLED_*, CONFIG_*, HAVE_* and TARGET_*. Some of
these can probably be mapped to autoconf default stuff, but for
everything else you'd still have to write code to set them.
Well, so if you call AC_CONFIG_SUBDIRS, basically your configure
calls the ffmpeg configure, so ffmpeg's configure just does that for
you like it always does. Essentially (this is purely theoretical),
ffmpeg doesn't even need to be autotools-based (oh god I can see the
replies on this one coming) _as long as it implements all the
relevant make targets_ (distcheck being the most important one for
me).
And takes autoconf command line arguments. I have some issues with
how autoconf handles arguments so that will never happen as long as
I'm in charge of it.
Post by Ronald S. Bultje
Like I said, I'm totally fine with adding all these make targets
to ffmpeg's build system manually, as long as it works (right now it
doesn't). IMHO it's just a lot easier to let it all be done
automatically by using auto* than doing it all manually. A quick wc -
l/-c shows that my Makefile.ams + configure.ac are currently +/- 2250
lines or 48000 bytes - how much is ffmpeg's configure + Makefile?
3311 lines. How big are your final configure and Makefiles? That's
what really matters.
--
Måns Rullgård
***@mansr.com
Diego Biurrun
2007-05-16 10:02:35 UTC
Permalink
Post by Måns Rullgård
Post by Ronald S. Bultje
Like I said, I'm totally fine with adding all these make targets
to ffmpeg's build system manually, as long as it works (right now it
doesn't). IMHO it's just a lot easier to let it all be done
automatically by using auto* than doing it all manually. A quick wc -
l/-c shows that my Makefile.ams + configure.ac are currently +/- 2250
lines or 48000 bytes - how much is ffmpeg's configure + Makefile?
3311 lines. How big are your final configure and Makefiles? That's
what really matters.
The comparison is not fair, Ronald's auto* stuff does not handle
conditional compilation nor build pkgconfig files and similar things.
If I dropped those features I'm sure I could reduce the line count in
the build system by at least 50%...

Diego
Reimar Döffinger
2007-05-14 18:49:28 UTC
Permalink
Hello,
Post by Ronald S. Bultje
Post by Reimar Döffinger
I think you misunderstood at least partially. The currently problem is
setting the whole ENABLED_*, CONFIG_*, HAVE_* and TARGET_*. Some of
these can probably be mapped to autoconf default stuff, but for
everything else you'd still have to write code to set them.
Well, so if you call AC_CONFIG_SUBDIRS, basically your configure
calls the ffmpeg configure, so ffmpeg's configure just does that for
you like it always does.
The scenario is still the one where you want only libav* directories,
thus you would not have ffmpeg's configure (since it is in the main dir,
which is not wanted) ;-) (which is one of the reasons why MPlayer
does not use it).

Greetings,
Reimar Döffinger
Diego Biurrun
2007-05-14 21:03:34 UTC
Permalink
IMHO it's just a lot easier to let it all be done automatically by
using auto* than doing it all manually. A quick wc - l/-c shows that
my Makefile.ams + configure.ac are currently +/- 2250 lines or 48000
bytes - how much is ffmpeg's configure + Makefile?
Where are they?

Diego
Ronald S. Bultje
2007-05-14 18:59:33 UTC
Permalink
Hi,
Post by Måns Rullgård
Post by Ronald S. Bultje
Like I said, I'm totally fine with adding all these make targets
to ffmpeg's build system manually, as long as it works (right now it
doesn't). IMHO it's just a lot easier to let it all be done
automatically by using auto* than doing it all manually. A quick wc -
l/-c shows that my Makefile.ams + configure.ac are currently +/- 2250
lines or 48000 bytes - how much is ffmpeg's configure + Makefile?
3311 lines. How big are your final configure and Makefiles? That's
what really matters.
Probably around a trillion or so. Why is this what matters? You don't
maintain it and it's not part of your final lav[cfu] binary. Like
Luca said, m4/.am language isn't that big a deal, it's (similar to C
code) the people writing it needing to have some clue.

Since you appear very negative towards this, let's be constructive
again, how do you suggest to keep it easy (as in a one-click action)
to integrate ffmpeg svn revisions into a foreign source tree for
development purposes?

Ronald
Måns Rullgård
2007-05-14 19:24:48 UTC
Permalink
Post by Ronald S. Bultje
Hi,
Post by Måns Rullgård
Post by Ronald S. Bultje
Like I said, I'm totally fine with adding all these make targets
to ffmpeg's build system manually, as long as it works (right now it
doesn't). IMHO it's just a lot easier to let it all be done
automatically by using auto* than doing it all manually. A quick wc -
l/-c shows that my Makefile.ams + configure.ac are currently +/- 2250
lines or 48000 bytes - how much is ffmpeg's configure + Makefile?
3311 lines. How big are your final configure and Makefiles? That's
what really matters.
Probably around a trillion or so. Why is this what matters? You don't
maintain it and it's not part of your final lav[cfu] binary. Like
A few reasons:

- It is what you have to sift through when it fucks up, as it inevitably
will.

- It is what is actually run when people build the package. The
FFmpeg configure script runs in a few seconds flat. Show me an
equivalent autoconf script that runs at even half that speed. Same
goes for makefiles. Despite what the automake authors may believe,
the make program actually takes a little time to parse each line.
Multiply a little by zillions and you'll find yourself with quite a
lot.

- It is what gets distributed in the tarball, increasing the download
size tenfold.
Post by Ronald S. Bultje
Since you appear very negative towards this, let's be constructive
again, how do you suggest to keep it easy (as in a one-click action)
to integrate ffmpeg svn revisions into a foreign source tree for
development purposes?
That naturally depends on what build system they use.
--
Måns Rullgård
***@mansr.com
Steve Lhomme
2007-05-14 19:54:26 UTC
Permalink
Post by Måns Rullgård
- It is what is actually run when people build the package. The
FFmpeg configure script runs in a few seconds flat.
FFMPEG's configure takes 2 minutes to run on MSys. The scripts are
totally not optimized on windows. Most of the time is taken when
scanning the files for possible codec/formats to enable/disable.

Steve
Ramiro Ribeiro Polla
2007-05-14 20:13:51 UTC
Permalink
Post by Steve Lhomme
Post by Måns Rullgård
- It is what is actually run when people build the package. The
FFmpeg configure script runs in a few seconds flat.
FFMPEG's configure takes 2 minutes to run on MSys.
It doesn't take that long here, altough it does take considerably longer
than Linux.
But then, any configure script on MSys takes considerably longer than on
Linux.
Post by Steve Lhomme
The scripts are totally not optimized on windows. Most of the time is
taken when scanning the files for possible codec/formats to
enable/disable.
Windows is not optimized for this task.

Ramiro Polla
Víctor Paesa
2007-05-14 20:35:31 UTC
Permalink
Hi,
Post by Ramiro Ribeiro Polla
Post by Steve Lhomme
Post by Måns Rullgård
- It is what is actually run when people build the package. The
FFmpeg configure script runs in a few seconds flat.
FFMPEG's configure takes 2 minutes to run on MSys.
It doesn't take that long here, altough it does take considerably longer
than Linux.
But then, any configure script on MSys takes considerably longer than on
Linux.
Right, the problem is that there is no equivalent to fork() under Win32
and MSys/Cygwin need to emulate it. Then any sub-shell command in configure
takes a lot of time.

By the way, Mans mentioned some time ago the trick of using pksh instead
of bash, and indeed works great, my configure under Cygwin takes about 46s,
instead of 83s.

Regards,
Víctor
Luca Barbato
2007-05-14 19:52:56 UTC
Permalink
Post by Ronald S. Bultje
Since you appear very negative towards this, let's be constructive
again, how do you suggest to keep it easy (as in a one-click action)
to integrate ffmpeg svn revisions into a foreign source tree for
development purposes?
you may:

- create a set of native build system rules (say m4 for autotools) that
embed the ffmpeg configure logic (as in enable/disable
{codec,parser,(de)muxer}, use them in you main build script to generate
config.mak and config.h

- just have a config.mak and a config.h pregenerated that fit your needs

Keep in mind that having some codebase used on a foreign source tree
with a foreign build system isn't exactly simple. (e.g. try to build a
cocoa application w/out using Xcode or Make but a plain Makefile for
gnumake)

lu
--
Luca Barbato

Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
Ronald S. Bultje
2007-05-14 19:02:02 UTC
Permalink
Hi Reimar,
Post by Reimar Döffinger
The scenario is still the one where you want only libav* directories,
thus you would not have ffmpeg's configure (since it is in the main
dir,
which is not wanted) ;-) (which is one of the reasons why MPlayer
does not use it).
Copy the configure to the parent dir as ffconfigure and off you go
(kind of dirty, I admit).

Ronald
Ronald S. Bultje
2007-05-14 21:38:44 UTC
Permalink
Hi Diego,

first, sorry for the threading, if you know of a way to fix that in
digest mode, please let me know...
Post by Diego Biurrun
IMHO it's just a lot easier to let it all be done automatically by
using auto* than doing it all manually. A quick wc - l/-c shows that
my Makefile.ams + configure.ac are currently +/- 2250 lines or 48000
bytes - how much is ffmpeg's configure + Makefile?
Where are they?
Google for autotools.patch, or attached. (And forgive me if the Mac
mailer breaks attachments also, I'm expecting that it will.)

Ronald
Diego Biurrun
2007-05-16 09:58:08 UTC
Permalink
Post by Ronald S. Bultje
first, sorry for the threading, if you know of a way to fix that in
digest mode, please let me know...
Not use digest mode? Try gmane if the volume of ffmpeg-devel drowns
you.
Post by Ronald S. Bultje
Post by Diego Biurrun
IMHO it's just a lot easier to let it all be done automatically by
using auto* than doing it all manually. A quick wc - l/-c shows that
my Makefile.ams + configure.ac are currently +/- 2250 lines or 48000
bytes - how much is ffmpeg's configure + Makefile?
Where are they?
Google for autotools.patch, or attached. (And forgive me if the Mac
mailer breaks attachments also, I'm expecting that it will.)
It sets the wrong mime type, but this is not hard to work around..

This patch mixes various unrelated changes, some of which are suitable
for upstream.
Post by Ronald S. Bultje
--- ffmpeg.orig/libavcodec/alpha/dsputil_alpha.c 2007-03-22 01:00:39.000000000 -0400
+++ ffmpeg/libavcodec/alpha/dsputil_alpha.c 2007-03-22 01:20:53.000000000 -0400
@@ -20,7 +20,7 @@
#include "asm.h"
-#include "../dsputil.h"
+#include "dsputil.h"
These are acceptable for us, I've committed them. Rejoice, this will
cut the size of this patch in half.
Post by Ronald S. Bultje
--- ffmpeg.orig/libavcodec/dct-test.c 2007-03-22 01:00:46.000000000 -0400
+++ ffmpeg/libavcodec/dct-test.c 2007-03-22 01:20:53.000000000 -0400
@@ -39,6 +39,7 @@
#define MAX(a, b) (((a) > (b)) ? (a) : (b))
#endif
+#undef fprintf
#undef printf
void *fast_memcpy(void *a, const void *b, size_t c){return memcpy(a,b,c);};
@@ -46,13 +47,17 @@
/* reference fdct/idct */
extern void fdct(DCTELEM *block);
extern void idct(DCTELEM *block);
+#if defined(HAVE_MMX) && defined(CONFIG_GPL)
extern void ff_idct_xvid_mmx(DCTELEM *block);
extern void ff_idct_xvid_mmx2(DCTELEM *block);
+#endif
extern void init_fdct();
extern void j_rev_dct(DCTELEM *data);
+#ifdef HAVE_MMX
extern void ff_mmx_idct(DCTELEM *data);
extern void ff_mmxext_idct(DCTELEM *data);
+#endif
extern void odivx_idct_c (short *block);
@@ -83,6 +88,7 @@
static short idct_mmx_perm[64];
+#ifdef HAVE_MMX
static short idct_simple_mmx_perm[64]={
0x00, 0x08, 0x04, 0x09, 0x01, 0x0C, 0x05, 0x0D,
0x10, 0x18, 0x14, 0x19, 0x11, 0x1C, 0x15, 0x1D,
@@ -93,6 +99,7 @@
0x22, 0x2A, 0x26, 0x2B, 0x23, 0x2E, 0x27, 0x2F,
0x32, 0x3A, 0x36, 0x3B, 0x33, 0x3E, 0x37, 0x3F,
};
+#endif
void idct_mmx_init(void)
{
@@ -162,14 +169,19 @@
for(i=0; i<64; i++)
block_org[i]= block1[i];
+#ifdef HAVE_MMX
if (fdct_func == ff_mmx_idct ||
fdct_func == j_rev_dct || fdct_func == ff_mmxext_idct) {
+#else
+ if (fdct_func == j_rev_dct) {
+#endif
for(i=0;i<64;i++)
block[idct_mmx_perm[i]] = block1[i];
+#ifdef HAVE_MMX
} else if(fdct_func == ff_simple_idct_mmx ) {
for(i=0;i<64;i++)
block[idct_simple_mmx_perm[i]] = block1[i];
-
+#endif
} else {
for(i=0; i<64; i++)
block[i]= block1[i];
@@ -184,7 +196,9 @@
#endif
fdct_func(block);
+#ifdef HAVE_MMX
emms(); /* for ff_mmx_idct */
+#endif
if (fdct_func == fdct_ifast
#ifndef FAAN_POSTSCALE
@@ -261,13 +275,19 @@
}break;
}
+#ifdef HAVE_MMX
if (fdct_func == ff_mmx_idct ||
fdct_func == j_rev_dct || fdct_func == ff_mmxext_idct) {
+#else
+ if (fdct_func == j_rev_dct) {
+#endif
for(i=0;i<64;i++)
block[idct_mmx_perm[i]] = block1[i];
+#ifdef HAVE_MMX
} else if(fdct_func == ff_simple_idct_mmx ) {
for(i=0;i<64;i++)
block[idct_simple_mmx_perm[i]] = block1[i];
+#endif
} else {
for(i=0; i<64; i++)
block[i]= block1[i];
@@ -286,7 +306,9 @@
it1 += NB_ITS_SPEED;
ti1 = gettime() - ti;
} while (ti1 < 1000000);
+#ifdef HAVE_MMX
emms();
+#endif
printf("%s %s: %0.1f kdct/s\n",
is_idct ? "IDCT" : "DCT",
@@ -446,7 +468,9 @@
it1 += NB_ITS_SPEED;
ti1 = gettime() - ti;
} while (ti1 < 1000000);
+#ifdef HAVE_MMX
emms();
+#endif
printf("%s %s: %0.1f kdct/s\n",
1 ? "IDCT248" : "DCT248",
@@ -508,18 +532,26 @@
dct_error("REF-DBL", 0, fdct, fdct, test); /* only to verify code ! */
dct_error("IJG-AAN-INT", 0, fdct_ifast, fdct, test);
dct_error("IJG-LLM-INT", 0, ff_jpeg_fdct_islow, fdct, test);
+#ifdef HAVE_MMX
dct_error("MMX", 0, ff_fdct_mmx, fdct, test);
dct_error("MMX2", 0, ff_fdct_mmx2, fdct, test);
+#endif
dct_error("FAAN", 0, ff_faandct, fdct, test);
} else {
dct_error("REF-DBL", 1, idct, idct, test);
dct_error("INT", 1, j_rev_dct, idct, test);
+#ifdef HAVE_MMX
dct_error("LIBMPEG2-MMX", 1, ff_mmx_idct, idct, test);
dct_error("LIBMPEG2-MMXEXT", 1, ff_mmxext_idct, idct, test);
+#endif
dct_error("SIMPLE-C", 1, simple_idct, idct, test);
+#ifdef HAVE_MMX
dct_error("SIMPLE-MMX", 1, ff_simple_idct_mmx, idct, test);
+#ifdef CONFIG_GPL
dct_error("XVID-MMX", 1, ff_idct_xvid_mmx, idct, test);
dct_error("XVID-MMX2", 1, ff_idct_xvid_mmx2, idct, test);
+#endif
+#endif
// dct_error("ODIVX-C", 1, odivx_idct_c, idct);
//printf(" test against odivx idct\n");
// dct_error("REF", 1, idct, odivx_idct_c);
Probably OK, you should submit this to us.
Post by Ronald S. Bultje
--- ffmpeg.orig/libavcodec/fft-test.c 2007-03-22 01:00:48.000000000 -0400
+++ ffmpeg/libavcodec/fft-test.c 2007-03-22 01:20:53.000000000 -0400
@@ -28,6 +28,9 @@
#include <unistd.h>
#include <sys/time.h>
+#undef fprintf
+#undef printf
+
int mm_flags;
dito
Post by Ronald S. Bultje
--- ffmpeg.orig/libavcodec/i386/cputest.c 2007-03-22 01:00:40.000000000 -0400
+++ ffmpeg/libavcodec/i386/cputest.c 2007-03-22 01:20:53.000000000 -0400
@@ -21,7 +21,7 @@
*/
#include <stdlib.h>
-#include "../dsputil.h"
+#include "dsputil.h"
#undef printf
@@ -120,6 +120,7 @@
}
#ifdef __TEST__
+#undef printf
int main ( void )
{
dito
Post by Ronald S. Bultje
--- ffmpeg.orig/libavcodec/imgresample.c 2007-03-22 01:00:47.000000000 -0400
+++ ffmpeg/libavcodec/imgresample.c 2007-03-22 01:20:53.000000000 -0400
@@ -28,8 +28,10 @@
#include "swscale.h"
#include "dsputil.h"
-#ifdef USE_FASTMEMCPY
-#include "libvo/fastmemcpy.h"
+#ifdef TEST
+#undef printf
+#undef fprintf
+#define av_log(p,l,...) fprintf(stderr,__VA_ARGS__)
#endif
Removing the #include is pointless, the rest is probably OK.
Post by Ronald S. Bultje
--- ffmpeg.orig/libavcodec/motion_test.c 2007-03-22 01:00:50.000000000 -0400
+++ ffmpeg/libavcodec/motion_test.c 2007-03-22 01:20:53.000000000 -0400
@@ -31,24 +31,27 @@
#include "dsputil.h"
+#ifdef HAVE_MMX
#include "i386/mmx.h"
+#endif
#undef printf
+#undef fprintf
-int pix_abs16x16_mmx(uint8_t *blk1, uint8_t *blk2, int lx);
-int pix_abs16x16_mmx1(uint8_t *blk1, uint8_t *blk2, int lx);
-int pix_abs16x16_c(uint8_t *blk1, uint8_t *blk2, int lx);
-int pix_abs16x16_x2_mmx(uint8_t *blk1, uint8_t *blk2, int lx);
-int pix_abs16x16_x2_mmx1(uint8_t *blk1, uint8_t *blk2, int lx);
-int pix_abs16x16_x2_c(uint8_t *blk1, uint8_t *blk2, int lx);
-int pix_abs16x16_y2_mmx(uint8_t *blk1, uint8_t *blk2, int lx);
-int pix_abs16x16_y2_mmx1(uint8_t *blk1, uint8_t *blk2, int lx);
-int pix_abs16x16_y2_c(uint8_t *blk1, uint8_t *blk2, int lx);
-int pix_abs16x16_xy2_mmx(uint8_t *blk1, uint8_t *blk2, int lx);
-int pix_abs16x16_xy2_mmx1(uint8_t *blk1, uint8_t *blk2, int lx);
-int pix_abs16x16_xy2_c(uint8_t *blk1, uint8_t *blk2, int lx);
+int pix_abs16x16_mmx(void *v, uint8_t *blk1, uint8_t *blk2, int lx, int h);
+int pix_abs16x16_mmx1(void *v, uint8_t *blk1, uint8_t *blk2, int lx, int h);
+int pix_abs16x16_c(void *v, uint8_t *blk1, uint8_t *blk2, int lx, int h);
+int pix_abs16x16_x2_mmx(void *v, uint8_t *blk1, uint8_t *blk2, int lx, int h);
+int pix_abs16x16_x2_mmx1(void *v, uint8_t *blk1, uint8_t *blk2, int lx, int h);
+int pix_abs16x16_x2_c(void *v, uint8_t *blk1, uint8_t *blk2, int lx, int h);
+int pix_abs16x16_y2_mmx(void *v, uint8_t *blk1, uint8_t *blk2, int lx, int h);
+int pix_abs16x16_y2_mmx1(void *v, uint8_t *blk1, uint8_t *blk2, int lx, int h);
+int pix_abs16x16_y2_c(void *v, uint8_t *blk1, uint8_t *blk2, int lx, int h);
+int pix_abs16x16_xy2_mmx(void *v, uint8_t *blk1, uint8_t *blk2, int lx, int h);
+int pix_abs16x16_xy2_mmx1(void *v, uint8_t *blk1, uint8_t *blk2, int lx, int h);
+int pix_abs16x16_xy2_c(void *v, uint8_t *blk1, uint8_t *blk2, int lx, int h);
-typedef int motion_func(uint8_t *blk1, uint8_t *blk2, int lx);
+typedef int motion_func(void *v, uint8_t *blk1, uint8_t *blk2, int lx, int h);
#define WIDTH 64
#define HEIGHT 64
@@ -103,15 +106,17 @@
for(y=0;y<HEIGHT-17;y++) {
for(x=0;x<WIDTH-17;x++) {
ptr = img2 + y * WIDTH + x;
- d1 = test_func(img1, ptr, WIDTH);
- d2 = ref_func(img1, ptr, WIDTH);
+ d1 = test_func(NULL, img1, ptr, WIDTH, 1);
+ d2 = ref_func(NULL, img1, ptr, WIDTH, 1);
if (d1 != d2) {
printf("error: mmx=%d c=%d\n", d1, d2);
}
}
}
}
+#ifdef HAVE_MMX
emms();
+#endif
/* speed test */
ti = gettime();
@@ -120,11 +125,13 @@
for(y=0;y<HEIGHT-17;y++) {
for(x=0;x<WIDTH-17;x++) {
ptr = img2 + y * WIDTH + x;
- d1 += test_func(img1, ptr, WIDTH);
+ d1 += test_func(NULL, img1, ptr, WIDTH, 1);
}
}
}
+#ifdef HAVE_MMX
emms();
+#endif
dummy = d1; /* avoid optimisation */
ti = gettime() - ti;
@@ -136,13 +143,17 @@
int main(int argc, char **argv)
{
- int c;
+ int n;
+#ifdef HAVE_MMX
+ AVCodecContext *ctx;
+ DSPContext c, mmx;
+#endif
for(;;) {
- c = getopt(argc, argv, "h");
- if (c == -1)
+ n = getopt(argc, argv, "h");
+ if (n == -1)
break;
- switch(c) {
+ switch(n) {
help();
break;
@@ -151,9 +162,25 @@
printf("ffmpeg motion test\n");
- test_motion("mmx", pix_abs16x16_mmx, pix_abs16x16_c);
- test_motion("mmx_x2", pix_abs16x16_x2_mmx, pix_abs16x16_x2_c);
- test_motion("mmx_y2", pix_abs16x16_y2_mmx, pix_abs16x16_y2_c);
- test_motion("mmx_xy2", pix_abs16x16_xy2_mmx, pix_abs16x16_xy2_c);
+#ifdef HAVE_MMX
+ ctx = avcodec_alloc_context();
+ mm_flags = 0;
+ dsputil_init(&c, ctx);
+ mm_flags = MM_MMX;
+ dsputil_init(&mmx, ctx);
+
+ test_motion("mmx/16", mmx.pix_abs[0][0], c.pix_abs[0][0]);
+ test_motion("mmx_x2/16", mmx.pix_abs[0][1], c.pix_abs[0][1]);
+ test_motion("mmx_y2/16", mmx.pix_abs[0][2], c.pix_abs[0][2]);
+ test_motion("mmx_xy2/16", mmx.pix_abs[0][3], c.pix_abs[0][3]);
+
+ test_motion("mmx/8", mmx.pix_abs[1][0], c.pix_abs[1][0]);
+ test_motion("mmx_x2/8", mmx.pix_abs[1][1], c.pix_abs[1][1]);
+ test_motion("mmx_y2/8", mmx.pix_abs[1][2], c.pix_abs[1][2]);
+ test_motion("mmx_xy2/8", mmx.pix_abs[1][3], c.pix_abs[1][3]);
+
+ av_free(ctx);
+#endif
+
return 0;
}
Might be OK.
Post by Ronald S. Bultje
--- ffmpeg.orig/libavformat/grab.c 2007-03-22 01:00:54.000000000 -0400
+++ ffmpeg/libavformat/grab.c 2007-03-22 01:20:53.000000000 -0400
@@ -431,7 +431,7 @@
}
#ifdef HAVE_MMX
-#include "libavcodec/i386/mmx.h"
+#include "i386/mmx.h"
@@ -582,7 +582,7 @@
#else
-#include "libavcodec/dsputil.h"
+#include "dsputil.h"
Committed.
Post by Ronald S. Bultje
--- ffmpeg.orig/tests/dsptest.c 2007-03-22 01:00:52.000000000 -0400
+++ ffmpeg/tests/dsptest.c 2007-03-22 01:20:53.000000000 -0400
@@ -22,16 +22,16 @@
#include "mpegvideo.h"
#include "mpeg12data.h"
#include "mpeg4data.h"
-#include "../libavcodec/i386/cputest.c"
-#include "../libavcodec/i386/dsputil_mmx.c"
+#include "i386/cputest.c"
+#include "i386/dsputil_mmx.c"
-#include "../libavcodec/i386/fdct_mmx.c"
-#include "../libavcodec/i386/idct_mmx.c"
-#include "../libavcodec/i386/motion_est_mmx.c"
-#include "../libavcodec/i386/simple_idct_mmx.c"
-#include "../libavcodec/dsputil.c"
-#include "../libavcodec/simple_idct.c"
-#include "../libavcodec/jfdctfst.c"
+#include "i386/fdct_mmx.c"
+#include "i386/idct_mmx.c"
+#include "i386/motion_est_mmx.c"
+#include "i386/simple_idct_mmx.c"
+#include "dsputil.c"
+#include "simple_idct.c"
+#include "jfdctfst.c"
This is OK, I'll commit it in a moment.
Post by Ronald S. Bultje
@@ -73,13 +73,13 @@
int mm_flags;
} pix_func[] = {
- PIX_FUNC_MMX(put_pixels),
+ PIX_FUNC_MMX(put_pixels8),
//PIX_FUNC_MMX(get_pixels),
//PIX_FUNC_MMX(put_pixels_clamped),
#if 1
- PIX_FUNC(put_pixels_x2),
- PIX_FUNC(put_pixels_y2),
- PIX_FUNC_MMX(put_pixels_xy2),
+ PIX_FUNC(put_pixels8_x2),
+ PIX_FUNC(put_pixels8_y2),
+ PIX_FUNC_MMX(put_pixels8_xy2),
Not sure about this part.
Post by Ronald S. Bultje
--- ffmpeg.orig/libavcodec/i386/h264dsp_mmx.c 2007-03-22 01:00:40.000000000 -0400
+++ ffmpeg/libavcodec/i386/h264dsp_mmx.c 2007-03-22 01:20:53.000000000 -0400
@@ -386,7 +386,7 @@
-static inline void h264_loop_filter_luma_mmx2(uint8_t *pix, int stride, int alpha1, int beta1, int8_t *tc0)
+static void h264_loop_filter_luma_mmx2(uint8_t *pix, int stride, int alpha1, int beta1, int8_t *tc0)
?
Post by Ronald S. Bultje
--- ffmpeg.orig/libavcodec/i386/snowdsp_mmx.c 2007-03-22 01:00:40.000000000 -0400
+++ ffmpeg/libavcodec/i386/snowdsp_mmx.c 2007-03-22 01:20:53.000000000 -0400
@@ -459,7 +459,6 @@
b2[i] += (W_BM*(b1[i] + b3[i])+4*b2[i]+W_BO)>>W_BS;
b1[i] += (W_AM*(b0[i] + b2[i])+W_AO)>>W_AS;
}
-
asm volatile (
"jmp 2f \n\t"
"1: \n\t"
@@ -566,7 +565,6 @@
b2[i] += (W_BM*(b1[i] + b3[i])+4*b2[i]+W_BO)>>W_BS;
b1[i] += (W_AM*(b0[i] + b2[i])+W_AO)>>W_AS;
}
-
asm volatile(
"jmp 2f \n\t"
"1: \n\t"
What for?
Post by Ronald S. Bultje
Index: ffmpeg/AUTHORS
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ ffmpeg/AUTHORS 2007-03-22 01:20:53.000000000 -0400
Index: ffmpeg/ChangeLog
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ ffmpeg/ChangeLog 2007-03-22 01:21:56.000000000 -0400
Why the heck do you duplicate these files?
Post by Ronald S. Bultje
Index: ffmpeg/libavcodec/liba52/Makefile.am
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ ffmpeg/libavcodec/liba52/Makefile.am 2007-03-22 01:20:53.000000000 -0400
This hasn't been updated in a while ...
Post by Ronald S. Bultje
Index: ffmpeg/libavcodec/.cvsignore
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ ffmpeg/libavcodec/.cvsignore 2007-03-22 01:20:53.000000000 -0400
Still using CVS?
Post by Ronald S. Bultje
Index: ffmpeg/libavcodec/allcodecs.c
===================================================================
--- ffmpeg.orig/libavcodec/allcodecs.c 2007-03-22 01:00:46.000000000 -0400
+++ ffmpeg/libavcodec/allcodecs.c 2007-03-22 01:20:53.000000000 -0400
@@ -96,7 +96,9 @@
REGISTER_ENCDEC (MJPEG, mjpeg);
REGISTER_DECODER(MJPEGB, mjpegb);
REGISTER_DECODER(MMVIDEO, mmvideo);
+#ifdef HAVE_XVMC
REGISTER_DECODER(MPEG_XVMC, mpeg_xvmc);
+#endif
We were glad to get rid of these. It seems our configure does have a
feature or two more than yours after all ...
Post by Ronald S. Bultje
Index: ffmpeg/libswscale/cs_test.c
===================================================================
--- ffmpeg.orig/libswscale/cs_test.c 2007-03-22 01:00:59.000000000 -0400
+++ ffmpeg/libswscale/cs_test.c 2007-03-22 09:03:57.000000000 -0400
@@ -23,7 +23,9 @@
#include <unistd.h>
#include <stdlib.h>
#include <inttypes.h>
+#ifdef HAVE_MALLOC_H
#include <malloc.h>
+#endif
#include "swscale.h"
#include "rgb2rgb.h"
@@ -34,6 +36,7 @@
#ifdef __APPLE_CC__
#define memalign(x,y) malloc(y)
+#undef malloc
#endif
likely acceptable

Diego
Michel Bardiaux
2007-05-16 10:12:54 UTC
Permalink
Post by Diego Biurrun
Post by Ronald S. Bultje
first, sorry for the threading, if you know of a way to fix that in
digest mode, please let me know...
Not use digest mode? Try gmane if the volume of ffmpeg-devel drowns
you.
As soon as a user of digest enters a thread, conversation becomes damsn
near impossible. Cant we make users of digest 'lurk only'?

Greetings,
--
Michel Bardiaux
R&D Director
T +32 [0] 2 790 29 41
F +32 [0] 2 790 29 02
E mailto:***@mediaxim.be

Mediaxim NV/SA
Vorstlaan 191 Boulevard du Souverain
Brussel 1160 Bruxelles
http://www.mediaxim.com/
Måns Rullgård
2007-05-16 10:26:07 UTC
Permalink
Post by Ronald S. Bultje
+#ifdef HAVE_MMX
emms(); /* for ff_mmx_idct */
+#endif
emms_c();
--
Måns Rullgård
***@mansr.com
Ronald S. Bultje
2007-05-20 18:05:44 UTC
Permalink
Hi,
Post by Diego Biurrun
Post by Ronald S. Bultje
first, sorry for the threading, if you know of a way to fix that in
digest mode, please let me know...
Not use digest mode? Try gmane if the volume of ffmpeg-devel drowns
you.
Let's see how this works. I tried webinterface, didn't work (too much
quoted text, no attachments), then tried nntp: with xnntp, didn't work
(couldn't send emails, or well it said it did, but it never actually
did, I think - maybe you'll get this message 10 times eventually), so
now I'm trying MT_NewsWatcher. Maybe this works. Let me know if
threading is OK now.
Post by Diego Biurrun
Post by Ronald S. Bultje
--- ffmpeg.orig/libavcodec/dct-test.c 2007-03-22 01:00:46.000000000 -0400
+++ ffmpeg/libavcodec/dct-test.c 2007-03-22 01:20:53.000000000 -0400
<at> <at> -39,6 +39,7 <at> <at>
#define MAX(a, b) (((a) > (b)) ? (a) : (b))
#endif
+#undef fprintf
#undef printf
void *fast_memcpy(void *a, const void *b, size_t c){return memcpy(a,b,c);};
<at> <at> -46,13 +47,17 <at> <at>
/* reference fdct/idct */
extern void fdct(DCTELEM *block);
extern void idct(DCTELEM *block);
+#if defined(HAVE_MMX) && defined(CONFIG_GPL)
extern void ff_idct_xvid_mmx(DCTELEM *block);
extern void ff_idct_xvid_mmx2(DCTELEM *block);
+#endif
extern void init_fdct();
extern void j_rev_dct(DCTELEM *data);
+#ifdef HAVE_MMX
extern void ff_mmx_idct(DCTELEM *data);
extern void ff_mmxext_idct(DCTELEM *data);
+#endif
extern void odivx_idct_c (short *block);
<at> <at> -83,6 +88,7 <at> <at>
static short idct_mmx_perm[64];
+#ifdef HAVE_MMX
static short idct_simple_mmx_perm[64]={
0x00, 0x08, 0x04, 0x09, 0x01, 0x0C, 0x05, 0x0D,
0x10, 0x18, 0x14, 0x19, 0x11, 0x1C, 0x15, 0x1D,
<at> <at> -93,6 +99,7 <at> <at>
0x22, 0x2A, 0x26, 0x2B, 0x23, 0x2E, 0x27, 0x2F,
0x32, 0x3A, 0x36, 0x3B, 0x33, 0x3E, 0x37, 0x3F,
};
+#endif
void idct_mmx_init(void)
{
<at> <at> -162,14 +169,19 <at> <at>
for(i=0; i<64; i++)
block_org[i]= block1[i];
+#ifdef HAVE_MMX
if (fdct_func == ff_mmx_idct ||
fdct_func == j_rev_dct || fdct_func == ff_mmxext_idct) {
+#else
+ if (fdct_func == j_rev_dct) {
+#endif
for(i=0;i<64;i++)
block[idct_mmx_perm[i]] = block1[i];
+#ifdef HAVE_MMX
} else if(fdct_func == ff_simple_idct_mmx ) {
for(i=0;i<64;i++)
block[idct_simple_mmx_perm[i]] = block1[i];
-
+#endif
} else {
for(i=0; i<64; i++)
block[i]= block1[i];
<at> <at> -184,7 +196,9 <at> <at>
#endif
fdct_func(block);
+#ifdef HAVE_MMX
emms(); /* for ff_mmx_idct */
+#endif
if (fdct_func == fdct_ifast
#ifndef FAAN_POSTSCALE
<at> <at> -261,13 +275,19 <at> <at>
}break;
}
+#ifdef HAVE_MMX
if (fdct_func == ff_mmx_idct ||
fdct_func == j_rev_dct || fdct_func == ff_mmxext_idct) {
+#else
+ if (fdct_func == j_rev_dct) {
+#endif
for(i=0;i<64;i++)
block[idct_mmx_perm[i]] = block1[i];
+#ifdef HAVE_MMX
} else if(fdct_func == ff_simple_idct_mmx ) {
for(i=0;i<64;i++)
block[idct_simple_mmx_perm[i]] = block1[i];
+#endif
} else {
for(i=0; i<64; i++)
block[i]= block1[i];
<at> <at> -286,7 +306,9 <at> <at>
it1 += NB_ITS_SPEED;
ti1 = gettime() - ti;
} while (ti1 < 1000000);
+#ifdef HAVE_MMX
emms();
+#endif
printf("%s %s: %0.1f kdct/s\n",
is_idct ? "IDCT" : "DCT",
<at> <at> -446,7 +468,9 <at> <at>
it1 += NB_ITS_SPEED;
ti1 = gettime() - ti;
} while (ti1 < 1000000);
+#ifdef HAVE_MMX
emms();
+#endif
printf("%s %s: %0.1f kdct/s\n",
1 ? "IDCT248" : "DCT248",
<at> <at> -508,18 +532,26 <at> <at>
dct_error("REF-DBL", 0, fdct, fdct, test); /* only to verify code ! */
dct_error("IJG-AAN-INT", 0, fdct_ifast, fdct, test);
dct_error("IJG-LLM-INT", 0, ff_jpeg_fdct_islow, fdct, test);
+#ifdef HAVE_MMX
dct_error("MMX", 0, ff_fdct_mmx, fdct, test);
dct_error("MMX2", 0, ff_fdct_mmx2, fdct, test);
+#endif
dct_error("FAAN", 0, ff_faandct, fdct, test);
} else {
dct_error("REF-DBL", 1, idct, idct, test);
dct_error("INT", 1, j_rev_dct, idct, test);
+#ifdef HAVE_MMX
dct_error("LIBMPEG2-MMX", 1, ff_mmx_idct, idct, test);
dct_error("LIBMPEG2-MMXEXT", 1, ff_mmxext_idct, idct, test);
+#endif
dct_error("SIMPLE-C", 1, simple_idct, idct, test);
+#ifdef HAVE_MMX
dct_error("SIMPLE-MMX", 1, ff_simple_idct_mmx, idct, test);
+#ifdef CONFIG_GPL
dct_error("XVID-MMX", 1, ff_idct_xvid_mmx, idct, test);
dct_error("XVID-MMX2", 1, ff_idct_xvid_mmx2, idct, test);
+#endif
+#endif
// dct_error("ODIVX-C", 1, odivx_idct_c, idct);
//printf(" test against odivx idct\n");
// dct_error("REF", 1, idct, odivx_idct_c);
Probably OK, you should submit this to us.
OK, see below.
Post by Diego Biurrun
Post by Ronald S. Bultje
--- ffmpeg.orig/libavcodec/imgresample.c 2007-03-22 01:00:47.000000000 -0400
+++ ffmpeg/libavcodec/imgresample.c 2007-03-22 01:20:53.000000000 -0400
<at> <at> -28,8 +28,10 <at> <at>
#include "swscale.h"
#include "dsputil.h"
-#ifdef USE_FASTMEMCPY
-#include "libvo/fastmemcpy.h"
+#ifdef TEST
+#undef printf
+#undef fprintf
+#define av_log(p,l,...) fprintf(stderr,__VA_ARGS__)
#endif
Removing the #include is pointless, the rest is probably OK.
So, I may remember this wrong, but I think the consensus a while ago
(there was a "discussion" on this way back) was that this didn't really
belong in ffmpeg, since it's mplayer-specific (see e.g "libvo/"). Other
similar mplayer-specific code (e.g. the fourcc hacks in wav/avi) has
also been removed in ffmpeg. In this case, mplayer could simply use
-include fastmemcpy.h (similar to how the linux kernel does this kind of
stuff) or change the sources if they want this. I've left it in for now,
feel free to remove it (a similar line is in swscale/rgb2rgb.c).
Post by Diego Biurrun
Post by Ronald S. Bultje
--- ffmpeg.orig/libavcodec/i386/h264dsp_mmx.c 2007-03-22 01:00:40.000000000 -0400
+++ ffmpeg/libavcodec/i386/h264dsp_mmx.c 2007-03-22 01:20:53.000000000 -0400
<at> <at> -386,7 +386,7 <at> <at>
-static inline void h264_loop_filter_luma_mmx2(uint8_t *pix, int stride, int alpha1, int beta1,
int8_t *tc0)
Post by Ronald S. Bultje
+static void h264_loop_filter_luma_mmx2(uint8_t *pix, int stride, int alpha1, int beta1, int8_t *tc0)
?
Post by Ronald S. Bultje
--- ffmpeg.orig/libavcodec/i386/snowdsp_mmx.c 2007-03-22 01:00:40.000000000 -0400
+++ ffmpeg/libavcodec/i386/snowdsp_mmx.c 2007-03-22 01:20:53.000000000 -0400
<at> <at> -459,7 +459,6 <at> <at>
b2[i] += (W_BM*(b1[i] + b3[i])+4*b2[i]+W_BO)>>W_BS;
b1[i] += (W_AM*(b0[i] + b2[i])+W_AO)>>W_AS;
}
-
asm volatile (
"jmp 2f \n\t"
"1: \n\t"
<at> <at> -566,7 +565,6 <at> <at>
b2[i] += (W_BM*(b1[i] + b3[i])+4*b2[i]+W_BO)>>W_BS;
b1[i] += (W_AM*(b0[i] + b2[i])+W_AO)>>W_AS;
}
-
asm volatile(
"jmp 2f \n\t"
"1: \n\t"
What for?
First is for broken compilers (which I had to work with for a while :) )
and the second is the removal of a similar hack for broken compilers
(there used to be alternate code there :) ) which I removed but
unfortunately removed newlines as well. Both removed.
Post by Diego Biurrun
Post by Ronald S. Bultje
Index: ffmpeg/AUTHORS
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ ffmpeg/AUTHORS 2007-03-22 01:20:53.000000000 -0400
Index: ffmpeg/ChangeLog
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ ffmpeg/ChangeLog 2007-03-22 01:21:56.000000000 -0400
Why the heck do you duplicate these files?
Auto-crack (those files are required for a default dist, with those
exact names and case).
Post by Diego Biurrun
Post by Ronald S. Bultje
Index: ffmpeg/libavcodec/liba52/Makefile.am
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ ffmpeg/libavcodec/liba52/Makefile.am 2007-03-22 01:20:53.000000000 -0400
This hasn't been updated in a while ...
Post by Ronald S. Bultje
Index: ffmpeg/libavcodec/.cvsignore
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ ffmpeg/libavcodec/.cvsignore 2007-03-22 01:20:53.000000000 -0400
Still using CVS?
Both removed (indeed, left-overs from cvs/liba52 time, both were no more
used as you may have guessed from libavcodec/Makefile.am). Thanks for
helping me find those. :-).
Post by Diego Biurrun
Post by Ronald S. Bultje
Index: ffmpeg/libavcodec/allcodecs.c
===================================================================
--- ffmpeg.orig/libavcodec/allcodecs.c 2007-03-22 01:00:46.000000000 -0400
+++ ffmpeg/libavcodec/allcodecs.c 2007-03-22 01:20:53.000000000 -0400
<at> <at> -96,7 +96,9 <at> <at>
REGISTER_ENCDEC (MJPEG, mjpeg);
REGISTER_DECODER(MJPEGB, mjpegb);
REGISTER_DECODER(MMVIDEO, mmvideo);
+#ifdef HAVE_XVMC
REGISTER_DECODER(MPEG_XVMC, mpeg_xvmc);
+#endif
We were glad to get rid of these. It seems our configure does have a
feature or two more than yours after all ...
Probably. I'll be honest here, I'm not yet very interested in adding
support for this, since A) the patch will never be accepted upstream
anyway and B) it's a fair piece of work with no gain at all since I
don't use it. For those part (ext. libs etc.) where I need it, I
re-added the compile conditionals to make it compile. It's not hard to
add it, and the patch would probably still be smaller (don't forget that
the patch w/o compile conditionals was smaller than ffmpeg's system
without compile conditionals also), I just don't want to spend the time
unless I feel it'll be useful. Essentially, I'll add it if there's a
chance that it goes upstream. I don't think that'll happen.
Alternatively, if I see a reason to use it, I'll add it also (and then
the above part of the patch will disappear).

Anyway, on to the relevant part of the patch for you. Attached, or if
that doesn't work on
http://people.freedesktop.org/~rbultje/ffmpeg_nommx.patch (still
testing...), you'll find those parts of the patch that you referenced
that I should submit separately. The patch does a bunch of things. First
of all, the gains: it allows most of the tests to be compiled (by
default, w/o mmx and w/o gpl). The changes that I made:

* most tests don't link to lav[ufc] and thus don't use av_log() but
printf(). However, for utility macros, they do include avutil.h, and
thus fail to compile b/c of the redefinition of av_log(). Thus, most
tests need a #undef printf/fprintf to compile. Similar for malloc in
swscale (last part of the patch).
* several tests reference mmx/gpl code w/o checking for whether this is
enabled. Those parts have been marked with appropriate compile
conditionals.
* as Mans suggested, emms -> emms_c
* in dsputil.c and dsputil_mmx.c/h264dsp_mmx.c, macros with the same
names are used. dsptest.c in tests/ includes both of those, and thus the
compile will give warnings. It's probably a good idea to #undef each of
them or use similar names. Both already use #undefs internally several
times for those variables (e.g. C[0-7]), since they're reused in various
places with different values within the same files. I simply added
#undefs at the end of where they're used also, so that multiple files
can use the same macro names. H264_{WEIGHT,MC} same story.
* fastmemcpy buggage, see above, remove if unwanted (I don't care if it
goes upstream, but I'll leave it in in my copy regardless).
* motion_test.c and dsptest.c had various API changes and I updated it
for those API changes. Worksforme[tm].

It's various changes together, but all of it is needed to make the tests
work, hence one big patch.

Have fun,
Ronald
Index: ffmpeg/libavcodec/dct-test.c
===================================================================
--- ffmpeg.orig/libavcodec/dct-test.c 2007-03-22 01:00:46.000000000 -0400
+++ ffmpeg/libavcodec/dct-test.c 2007-05-20 12:53:45.000000000 -0400
@@ -39,6 +39,7 @@
#define MAX(a, b) (((a) > (b)) ? (a) : (b))
#endif

+#undef fprintf
#undef printf

void *fast_memcpy(void *a, const void *b, size_t c){return memcpy(a,b,c);};
@@ -46,13 +47,17 @@
/* reference fdct/idct */
extern void fdct(DCTELEM *block);
extern void idct(DCTELEM *block);
+#if defined(HAVE_MMX) && defined(CONFIG_GPL)
extern void ff_idct_xvid_mmx(DCTELEM *block);
extern void ff_idct_xvid_mmx2(DCTELEM *block);
+#endif
extern void init_fdct();

extern void j_rev_dct(DCTELEM *data);
+#ifdef HAVE_MMX
extern void ff_mmx_idct(DCTELEM *data);
extern void ff_mmxext_idct(DCTELEM *data);
+#endif

extern void odivx_idct_c (short *block);

@@ -83,6 +88,7 @@

static short idct_mmx_perm[64];

+#ifdef HAVE_MMX
static short idct_simple_mmx_perm[64]={
0x00, 0x08, 0x04, 0x09, 0x01, 0x0C, 0x05, 0x0D,
0x10, 0x18, 0x14, 0x19, 0x11, 0x1C, 0x15, 0x1D,
@@ -93,6 +99,7 @@
0x22, 0x2A, 0x26, 0x2B, 0x23, 0x2E, 0x27, 0x2F,
0x32, 0x3A, 0x36, 0x3B, 0x33, 0x3E, 0x37, 0x3F,
};
+#endif

void idct_mmx_init(void)
{
@@ -162,14 +169,19 @@
for(i=0; i<64; i++)
block_org[i]= block1[i];

+#ifdef HAVE_MMX
if (fdct_func == ff_mmx_idct ||
fdct_func == j_rev_dct || fdct_func == ff_mmxext_idct) {
+#else
+ if (fdct_func == j_rev_dct) {
+#endif
for(i=0;i<64;i++)
block[idct_mmx_perm[i]] = block1[i];
+#ifdef HAVE_MMX
} else if(fdct_func == ff_simple_idct_mmx ) {
for(i=0;i<64;i++)
block[idct_simple_mmx_perm[i]] = block1[i];
-
+#endif
} else {
for(i=0; i<64; i++)
block[i]= block1[i];
@@ -184,7 +196,7 @@
#endif

fdct_func(block);
- emms(); /* for ff_mmx_idct */
+ emms_c(); /* for ff_mmx_idct */

if (fdct_func == fdct_ifast
#ifndef FAAN_POSTSCALE
@@ -261,13 +273,19 @@
}break;
}

+#ifdef HAVE_MMX
if (fdct_func == ff_mmx_idct ||
fdct_func == j_rev_dct || fdct_func == ff_mmxext_idct) {
+#else
+ if (fdct_func == j_rev_dct) {
+#endif
for(i=0;i<64;i++)
block[idct_mmx_perm[i]] = block1[i];
+#ifdef HAVE_MMX
} else if(fdct_func == ff_simple_idct_mmx ) {
for(i=0;i<64;i++)
block[idct_simple_mmx_perm[i]] = block1[i];
+#endif
} else {
for(i=0; i<64; i++)
block[i]= block1[i];
@@ -286,7 +304,7 @@
it1 += NB_ITS_SPEED;
ti1 = gettime() - ti;
} while (ti1 < 1000000);
- emms();
+ emms_c();

printf("%s %s: %0.1f kdct/s\n",
is_idct ? "IDCT" : "DCT",
@@ -446,7 +464,7 @@
it1 += NB_ITS_SPEED;
ti1 = gettime() - ti;
} while (ti1 < 1000000);
- emms();
+ emms_c();

printf("%s %s: %0.1f kdct/s\n",
1 ? "IDCT248" : "DCT248",
@@ -508,18 +526,26 @@
dct_error("REF-DBL", 0, fdct, fdct, test); /* only to verify code ! */
dct_error("IJG-AAN-INT", 0, fdct_ifast, fdct, test);
dct_error("IJG-LLM-INT", 0, ff_jpeg_fdct_islow, fdct, test);
+#ifdef HAVE_MMX
dct_error("MMX", 0, ff_fdct_mmx, fdct, test);
dct_error("MMX2", 0, ff_fdct_mmx2, fdct, test);
+#endif
dct_error("FAAN", 0, ff_faandct, fdct, test);
} else {
dct_error("REF-DBL", 1, idct, idct, test);
dct_error("INT", 1, j_rev_dct, idct, test);
+#ifdef HAVE_MMX
dct_error("LIBMPEG2-MMX", 1, ff_mmx_idct, idct, test);
dct_error("LIBMPEG2-MMXEXT", 1, ff_mmxext_idct, idct, test);
+#endif
dct_error("SIMPLE-C", 1, simple_idct, idct, test);
+#ifdef HAVE_MMX
dct_error("SIMPLE-MMX", 1, ff_simple_idct_mmx, idct, test);
+#ifdef CONFIG_GPL
dct_error("XVID-MMX", 1, ff_idct_xvid_mmx, idct, test);
dct_error("XVID-MMX2", 1, ff_idct_xvid_mmx2, idct, test);
+#endif
+#endif
// dct_error("ODIVX-C", 1, odivx_idct_c, idct);
//printf(" test against odivx idct\n");
// dct_error("REF", 1, idct, odivx_idct_c);
Index: ffmpeg/libavcodec/fft-test.c
===================================================================
--- ffmpeg.orig/libavcodec/fft-test.c 2007-03-22 01:00:48.000000000 -0400
+++ ffmpeg/libavcodec/fft-test.c 2007-03-22 01:20:53.000000000 -0400
@@ -28,6 +28,9 @@
#include <unistd.h>
#include <sys/time.h>

+#undef fprintf
+#undef printf
+
int mm_flags;

/* reference fft */
Index: ffmpeg/libavcodec/i386/cputest.c
===================================================================
--- ffmpeg.orig/libavcodec/i386/cputest.c 2007-03-22 01:00:40.000000000 -0400
+++ ffmpeg/libavcodec/i386/cputest.c 2007-03-22 01:20:53.000000000 -0400
@@ -120,6 +120,7 @@
}

#ifdef __TEST__
+#undef printf
int main ( void )
{
int mm_flags;
Index: ffmpeg/libavcodec/i386/dsputil_mmx.c
===================================================================
--- ffmpeg.orig/libavcodec/i386/dsputil_mmx.c 2007-03-22 01:00:40.000000000 -0400
+++ ffmpeg/libavcodec/i386/dsputil_mmx.c 2007-05-20 12:11:02.000000000 -0400
@@ -3457,6 +3457,7 @@
dspfunc(put_2tap_qpel, 1, 8);
dspfunc(avg_2tap_qpel, 0, 16);
dspfunc(avg_2tap_qpel, 1, 8);
+#undef dspfunc

c->avg_h264_chroma_pixels_tab[0]= avg_h264_chroma_mc8_3dnow;
c->avg_h264_chroma_pixels_tab[1]= avg_h264_chroma_mc4_3dnow;
Index: ffmpeg/libavcodec/i386/fdct_mmx.c
===================================================================
--- ffmpeg.orig/libavcodec/i386/fdct_mmx.c 2007-03-22 01:00:40.000000000 -0400
+++ ffmpeg/libavcodec/i386/fdct_mmx.c 2007-05-20 12:02:36.000000000 -0400
@@ -281,6 +281,13 @@
#define C6 12299
#define C7 6270
TABLE_SSE2
+#undef C1
+#undef C2
+#undef C3
+#undef C4
+#undef C5
+#undef C6
+#undef C7
}};


Index: ffmpeg/libavcodec/i386/simple_idct_mmx.c
===================================================================
--- ffmpeg.orig/libavcodec/i386/simple_idct_mmx.c 2007-03-22 01:00:40.000000000 -0400
+++ ffmpeg/libavcodec/i386/simple_idct_mmx.c 2007-05-20 12:09:00.000000000 -0400
@@ -77,6 +77,14 @@

C7, -C5, C7, -C5,
C3, -C1, C3, -C1
+#undef C0
+#undef C1
+#undef C2
+#undef C3
+#undef C4
+#undef C5
+#undef C6
+#undef C7
};

#if 0
@@ -87,14 +95,6 @@

static void inline idctCol (int16_t * col, int16_t *input)
{
-#undef C0
-#undef C1
-#undef C2
-#undef C3
-#undef C4
-#undef C5
-#undef C6
-#undef C7
int a0, a1, a2, a3, b0, b1, b2, b3;
const int C0 = 23170; //cos(i*M_PI/16)*sqrt(2)*(1<<14) + 0.5
const int C1 = 22725; //cos(i*M_PI/16)*sqrt(2)*(1<<14) + 0.5
Index: ffmpeg/libavcodec/imgresample.c
===================================================================
--- ffmpeg.orig/libavcodec/imgresample.c 2007-03-22 01:00:47.000000000 -0400
+++ ffmpeg/libavcodec/imgresample.c 2007-03-22 01:20:53.000000000 -0400
@@ -28,8 +28,10 @@
#include "swscale.h"
#include "dsputil.h"

-#ifdef USE_FASTMEMCPY
-#include "libvo/fastmemcpy.h"
+#ifdef TEST
+#undef printf
+#undef fprintf
+#define av_log(p,l,...) fprintf(stderr,__VA_ARGS__)
#endif

#define NB_COMPONENTS 3
@@ -835,7 +837,9 @@
fprintf(f,"P5\n%d %d\n%d\n", xsize, ysize, 255);
fwrite(img,1, xsize * ysize,f);
fclose(f);
+#ifndef TEST
#define fprintf please_use_av_log
+#endif
}

static void dump_filter(int16_t *filter)
Index: ffmpeg/libavcodec/motion_test.c
===================================================================
--- ffmpeg.orig/libavcodec/motion_test.c 2007-03-22 01:00:50.000000000 -0400
+++ ffmpeg/libavcodec/motion_test.c 2007-05-20 12:55:02.000000000 -0400
@@ -31,24 +31,27 @@

#include "dsputil.h"

+#ifdef HAVE_MMX
#include "i386/mmx.h"
+#endif

#undef printf
+#undef fprintf

-int pix_abs16x16_mmx(uint8_t *blk1, uint8_t *blk2, int lx);
-int pix_abs16x16_mmx1(uint8_t *blk1, uint8_t *blk2, int lx);
-int pix_abs16x16_c(uint8_t *blk1, uint8_t *blk2, int lx);
-int pix_abs16x16_x2_mmx(uint8_t *blk1, uint8_t *blk2, int lx);
-int pix_abs16x16_x2_mmx1(uint8_t *blk1, uint8_t *blk2, int lx);
-int pix_abs16x16_x2_c(uint8_t *blk1, uint8_t *blk2, int lx);
-int pix_abs16x16_y2_mmx(uint8_t *blk1, uint8_t *blk2, int lx);
-int pix_abs16x16_y2_mmx1(uint8_t *blk1, uint8_t *blk2, int lx);
-int pix_abs16x16_y2_c(uint8_t *blk1, uint8_t *blk2, int lx);
-int pix_abs16x16_xy2_mmx(uint8_t *blk1, uint8_t *blk2, int lx);
-int pix_abs16x16_xy2_mmx1(uint8_t *blk1, uint8_t *blk2, int lx);
-int pix_abs16x16_xy2_c(uint8_t *blk1, uint8_t *blk2, int lx);
+int pix_abs16x16_mmx(void *v, uint8_t *blk1, uint8_t *blk2, int lx, int h);
+int pix_abs16x16_mmx1(void *v, uint8_t *blk1, uint8_t *blk2, int lx, int h);
+int pix_abs16x16_c(void *v, uint8_t *blk1, uint8_t *blk2, int lx, int h);
+int pix_abs16x16_x2_mmx(void *v, uint8_t *blk1, uint8_t *blk2, int lx, int h);
+int pix_abs16x16_x2_mmx1(void *v, uint8_t *blk1, uint8_t *blk2, int lx, int h);
+int pix_abs16x16_x2_c(void *v, uint8_t *blk1, uint8_t *blk2, int lx, int h);
+int pix_abs16x16_y2_mmx(void *v, uint8_t *blk1, uint8_t *blk2, int lx, int h);
+int pix_abs16x16_y2_mmx1(void *v, uint8_t *blk1, uint8_t *blk2, int lx, int h);
+int pix_abs16x16_y2_c(void *v, uint8_t *blk1, uint8_t *blk2, int lx, int h);
+int pix_abs16x16_xy2_mmx(void *v, uint8_t *blk1, uint8_t *blk2, int lx, int h);
+int pix_abs16x16_xy2_mmx1(void *v, uint8_t *blk1, uint8_t *blk2, int lx, int h);
+int pix_abs16x16_xy2_c(void *v, uint8_t *blk1, uint8_t *blk2, int lx, int h);

-typedef int motion_func(uint8_t *blk1, uint8_t *blk2, int lx);
+typedef int motion_func(void *v, uint8_t *blk1, uint8_t *blk2, int lx, int h);

#define WIDTH 64
#define HEIGHT 64
@@ -103,15 +106,15 @@
for(y=0;y<HEIGHT-17;y++) {
for(x=0;x<WIDTH-17;x++) {
ptr = img2 + y * WIDTH + x;
- d1 = test_func(img1, ptr, WIDTH);
- d2 = ref_func(img1, ptr, WIDTH);
+ d1 = test_func(NULL, img1, ptr, WIDTH, 1);
+ d2 = ref_func(NULL, img1, ptr, WIDTH, 1);
if (d1 != d2) {
printf("error: mmx=%d c=%d\n", d1, d2);
}
}
}
}
- emms();
+ emms_c();

/* speed test */
ti = gettime();
@@ -120,11 +123,11 @@
for(y=0;y<HEIGHT-17;y++) {
for(x=0;x<WIDTH-17;x++) {
ptr = img2 + y * WIDTH + x;
- d1 += test_func(img1, ptr, WIDTH);
+ d1 += test_func(NULL, img1, ptr, WIDTH, 1);
}
}
}
- emms();
+ emms_c();
dummy = d1; /* avoid optimisation */
ti = gettime() - ti;

@@ -136,13 +139,17 @@

int main(int argc, char **argv)
{
- int c;
+ int n;
+#ifdef HAVE_MMX
+ AVCodecContext *ctx;
+ DSPContext c, mmx;
+#endif

for(;;) {
- c = getopt(argc, argv, "h");
- if (c == -1)
+ n = getopt(argc, argv, "h");
+ if (n == -1)
break;
- switch(c) {
+ switch(n) {
case 'h':
help();
break;
@@ -151,9 +158,25 @@

printf("ffmpeg motion test\n");

- test_motion("mmx", pix_abs16x16_mmx, pix_abs16x16_c);
- test_motion("mmx_x2", pix_abs16x16_x2_mmx, pix_abs16x16_x2_c);
- test_motion("mmx_y2", pix_abs16x16_y2_mmx, pix_abs16x16_y2_c);
- test_motion("mmx_xy2", pix_abs16x16_xy2_mmx, pix_abs16x16_xy2_c);
+#ifdef HAVE_MMX
+ ctx = avcodec_alloc_context();
+ mm_flags = 0;
+ dsputil_init(&c, ctx);
+ mm_flags = MM_MMX;
+ dsputil_init(&mmx, ctx);
+
+ test_motion("mmx/16", mmx.pix_abs[0][0], c.pix_abs[0][0]);
+ test_motion("mmx_x2/16", mmx.pix_abs[0][1], c.pix_abs[0][1]);
+ test_motion("mmx_y2/16", mmx.pix_abs[0][2], c.pix_abs[0][2]);
+ test_motion("mmx_xy2/16", mmx.pix_abs[0][3], c.pix_abs[0][3]);
+
+ test_motion("mmx/8", mmx.pix_abs[1][0], c.pix_abs[1][0]);
+ test_motion("mmx_x2/8", mmx.pix_abs[1][1], c.pix_abs[1][1]);
+ test_motion("mmx_y2/8", mmx.pix_abs[1][2], c.pix_abs[1][2]);
+ test_motion("mmx_xy2/8", mmx.pix_abs[1][3], c.pix_abs[1][3]);
+
+ av_free(ctx);
+#endif
+
return 0;
}
Index: ffmpeg/libavformat/grab.c
===================================================================
--- ffmpeg.orig/libavformat/grab.c 2007-03-22 01:00:54.000000000 -0400
+++ ffmpeg/libavformat/grab.c 2007-05-20 12:55:11.000000000 -0400
@@ -846,9 +846,7 @@
DEINT_LINE_LUM(12)
}
}
-#ifdef HAVE_MMX
- emms();
-#endif
+ emms_c();
return s->frame_size;
}

Index: ffmpeg/tests/dsptest.c
===================================================================
--- ffmpeg.orig/tests/dsptest.c 2007-03-22 01:00:52.000000000 -0400
+++ ffmpeg/tests/dsptest.c 2007-05-20 12:50:47.000000000 -0400
@@ -20,18 +20,18 @@
#include "avcodec.h"
#include "dsputil.h"
#include "mpegvideo.h"
-#include "mpeg12data.h"
-#include "mpeg4data.h"
-#include "../libavcodec/i386/cputest.c"
-#include "../libavcodec/i386/dsputil_mmx.c"
-
-#include "../libavcodec/i386/fdct_mmx.c"
-#include "../libavcodec/i386/idct_mmx.c"
-#include "../libavcodec/i386/motion_est_mmx.c"
-#include "../libavcodec/i386/simple_idct_mmx.c"
-#include "../libavcodec/dsputil.c"
-#include "../libavcodec/simple_idct.c"
-#include "../libavcodec/jfdctfst.c"
+//#include "mpeg12data.h"
+//#include "mpeg4data.h"
+#include "i386/cputest.c"
+#include "i386/dsputil_mmx.c"
+
+#include "i386/fdct_mmx.c"
+#include "i386/idct_mmx.c"
+#include "i386/motion_est_mmx.c"
+#include "i386/simple_idct_mmx.c"
+#include "dsputil.c"
+#include "simple_idct.c"
+#include "jfdctfst.c"

#undef TESTCPU_MAIN

@@ -73,27 +73,27 @@
int mm_flags;
} pix_func[] = {

- PIX_FUNC_MMX(put_pixels),
+ PIX_FUNC_MMX(put_pixels8),
//PIX_FUNC_MMX(get_pixels),
//PIX_FUNC_MMX(put_pixels_clamped),
#if 1
- PIX_FUNC(put_pixels_x2),
- PIX_FUNC(put_pixels_y2),
- PIX_FUNC_MMX(put_pixels_xy2),
-
- PIX_FUNC(put_no_rnd_pixels_x2),
- PIX_FUNC(put_no_rnd_pixels_y2),
- PIX_FUNC_MMX(put_no_rnd_pixels_xy2),
-
- PIX_FUNC(avg_pixels),
- PIX_FUNC(avg_pixels_x2),
- PIX_FUNC(avg_pixels_y2),
- PIX_FUNC(avg_pixels_xy2),
-
- PIX_FUNC_MMX(avg_no_rnd_pixels),
- PIX_FUNC_MMX(avg_no_rnd_pixels_x2),
- PIX_FUNC_MMX(avg_no_rnd_pixels_y2),
- PIX_FUNC_MMX(avg_no_rnd_pixels_xy2),
+ PIX_FUNC(put_pixels8_x2),
+ PIX_FUNC(put_pixels8_y2),
+ PIX_FUNC_MMX(put_pixels8_xy2),
+
+ PIX_FUNC(put_no_rnd_pixels8_x2),
+ PIX_FUNC(put_no_rnd_pixels8_y2),
+ PIX_FUNC_MMX(put_no_rnd_pixels8_xy2),
+
+ PIX_FUNC(avg_pixels8),
+ PIX_FUNC(avg_pixels8_x2),
+ PIX_FUNC(avg_pixels8_y2),
+ PIX_FUNC(avg_pixels8_xy2),
+
+ PIX_FUNC_MMX(avg_no_rnd_pixels8),
+ PIX_FUNC_MMX(avg_no_rnd_pixels8_x2),
+ PIX_FUNC_MMX(avg_no_rnd_pixels8_y2),
+ PIX_FUNC_MMX(avg_no_rnd_pixels8_xy2),
#endif
{ 0, 0 }
};
Index: ffmpeg/libavcodec/i386/h264dsp_mmx.c
===================================================================
--- ffmpeg.orig/libavcodec/i386/h264dsp_mmx.c 2007-03-22 01:00:40.000000000 -0400
+++ ffmpeg/libavcodec/i386/h264dsp_mmx.c 2007-05-20 12:13:28.000000000 -0400
@@ -1374,7 +1374,7 @@
H264_MC(avg_, 4, mmx2)
H264_MC(avg_, 8, mmx2)
H264_MC(avg_, 16,mmx2)
-
+#undef H264_MC

#define H264_CHROMA_OP(S,D)
#define H264_CHROMA_OP4(S,D,T)
@@ -1514,4 +1514,4 @@
H264_WEIGHT( 4, 8)
H264_WEIGHT( 4, 4)
H264_WEIGHT( 4, 2)
-
+#undef H264_WEIGHT
Index: ffmpeg/libswscale/rgb2rgb.c
===================================================================
--- ffmpeg.orig/libswscale/rgb2rgb.c 2007-03-22 01:00:59.000000000 -0400
+++ ffmpeg/libswscale/rgb2rgb.c 2007-03-22 01:20:53.000000000 -0400
@@ -33,9 +33,6 @@
#include "swscale_internal.h"
#include "x86_cpu.h"
#include "bswap.h"
-#ifdef USE_FASTMEMCPY
-#include "libvo/fastmemcpy.h"
-#endif

#define FAST_BGR2YV12 // use 7 bit coeffs instead of 15bit

Index: ffmpeg/libswscale/cs_test.c
===================================================================
--- ffmpeg.orig/libswscale/cs_test.c 2007-03-22 01:00:59.000000000 -0400
+++ ffmpeg/libswscale/cs_test.c 2007-03-22 09:03:57.000000000 -0400
@@ -23,7 +23,9 @@
#include <unistd.h>
#include <stdlib.h>
#include <inttypes.h>
+#ifdef HAVE_MALLOC_H
#include <malloc.h>
+#endif

#include "swscale.h"
#include "rgb2rgb.h"
@@ -34,6 +36,7 @@

#ifdef __APPLE_CC__
#define memalign(x,y) malloc(y)
+#undef malloc
#endif

static int cpu_caps;
Michael Niedermayer
2007-05-20 20:26:30 UTC
Permalink
Hi
Post by Ronald S. Bultje
Hi,
Post by Diego Biurrun
Post by Ronald S. Bultje
first, sorry for the threading, if you know of a way to fix that in
digest mode, please let me know...
Not use digest mode? Try gmane if the volume of ffmpeg-devel drowns
you.
Let's see how this works. I tried webinterface, didn't work (too much
quoted text, no attachments), then tried nntp: with xnntp, didn't work
gmane sucks :)
ive had a few problems with it posting to the git ML too, a single "hi" at
the top was enough to reject the mail as top posting ...


[...]
Post by Ronald S. Bultje
Anyway, on to the relevant part of the patch for you. Attached, or if
that doesn't work on
http://people.freedesktop.org/~rbultje/ffmpeg_nommx.patch (still
testing...), you'll find those parts of the patch that you referenced
that I should submit separately. The patch does a bunch of things. First
of all, the gains: it allows most of the tests to be compiled (by
* most tests don't link to lav[ufc] and thus don't use av_log() but
printf(). However, for utility macros, they do include avutil.h, and
thus fail to compile b/c of the redefinition of av_log(). Thus, most
tests need a #undef printf/fprintf to compile. Similar for malloc in
swscale (last part of the patch).
* several tests reference mmx/gpl code w/o checking for whether this is
enabled. Those parts have been marked with appropriate compile
conditionals.
* as Mans suggested, emms -> emms_c
* in dsputil.c and dsputil_mmx.c/h264dsp_mmx.c, macros with the same
names are used. dsptest.c in tests/ includes both of those, and thus the
compile will give warnings. It's probably a good idea to #undef each of
them or use similar names. Both already use #undefs internally several
times for those variables (e.g. C[0-7]), since they're reused in various
places with different values within the same files. I simply added
#undefs at the end of where they're used also, so that multiple files
can use the same macro names. H264_{WEIGHT,MC} same story.
* fastmemcpy buggage, see above, remove if unwanted (I don't care if it
goes upstream, but I'll leave it in in my copy regardless).
* motion_test.c and dsptest.c had various API changes and I updated it
for those API changes. Worksforme[tm].
It's various changes together, but all of it is needed to make the tests
work, hence one big patch.
split it :)

a quick review is below anyway but spliting it is needed if you want it to
be applied


[...]
Post by Ronald S. Bultje
@@ -46,13 +47,17 @@
/* reference fdct/idct */
extern void fdct(DCTELEM *block);
extern void idct(DCTELEM *block);
+#if defined(HAVE_MMX) && defined(CONFIG_GPL)
extern void ff_idct_xvid_mmx(DCTELEM *block);
extern void ff_idct_xvid_mmx2(DCTELEM *block);
+#endif
extern void init_fdct();
extern void j_rev_dct(DCTELEM *data);
+#ifdef HAVE_MMX
extern void ff_mmx_idct(DCTELEM *data);
extern void ff_mmxext_idct(DCTELEM *data);
+#endif
sensless
Post by Ronald S. Bultje
extern void odivx_idct_c (short *block);
@@ -83,6 +88,7 @@
static short idct_mmx_perm[64];
+#ifdef HAVE_MMX
static short idct_simple_mmx_perm[64]={
0x00, 0x08, 0x04, 0x09, 0x01, 0x0C, 0x05, 0x0D,
0x10, 0x18, 0x14, 0x19, 0x11, 0x1C, 0x15, 0x1D,
@@ -93,6 +99,7 @@
0x22, 0x2A, 0x26, 0x2B, 0x23, 0x2E, 0x27, 0x2F,
0x32, 0x3A, 0x36, 0x3B, 0x33, 0x3E, 0x37, 0x3F,
};
+#endif
this too is senseless, its not as if 128 byte would matter for a test
which isnt compiled or used during normal use
Post by Ronald S. Bultje
void idct_mmx_init(void)
{
@@ -162,14 +169,19 @@
for(i=0; i<64; i++)
block_org[i]= block1[i];
+#ifdef HAVE_MMX
if (fdct_func == ff_mmx_idct ||
fdct_func == j_rev_dct || fdct_func == ff_mmxext_idct) {
+#else
+ if (fdct_func == j_rev_dct) {
+#endif
tab
and
finding a solution which doesnt spice up all the code with #ifdefs would
be highly prefered, that is
#define ff_mmx_idct NULL ifn MMX
or some totally different way of checking the type


[...]
Post by Ronald S. Bultje
@@ -508,18 +526,26 @@
dct_error("REF-DBL", 0, fdct, fdct, test); /* only to verify code ! */
dct_error("IJG-AAN-INT", 0, fdct_ifast, fdct, test);
dct_error("IJG-LLM-INT", 0, ff_jpeg_fdct_islow, fdct, test);
+#ifdef HAVE_MMX
dct_error("MMX", 0, ff_fdct_mmx, fdct, test);
dct_error("MMX2", 0, ff_fdct_mmx2, fdct, test);
+#endif
dct_error("FAAN", 0, ff_faandct, fdct, test);
} else {
dct_error("REF-DBL", 1, idct, idct, test);
dct_error("INT", 1, j_rev_dct, idct, test);
+#ifdef HAVE_MMX
dct_error("LIBMPEG2-MMX", 1, ff_mmx_idct, idct, test);
dct_error("LIBMPEG2-MMXEXT", 1, ff_mmxext_idct, idct, test);
+#endif
dct_error("SIMPLE-C", 1, simple_idct, idct, test);
+#ifdef HAVE_MMX
dct_error("SIMPLE-MMX", 1, ff_simple_idct_mmx, idct, test);
+#ifdef CONFIG_GPL
dct_error("XVID-MMX", 1, ff_idct_xvid_mmx, idct, test);
dct_error("XVID-MMX2", 1, ff_idct_xvid_mmx2, idct, test);
+#endif
+#endif
sort them so as to minimize the #ifdef please
Post by Ronald S. Bultje
// dct_error("ODIVX-C", 1, odivx_idct_c, idct);
//printf(" test against odivx idct\n");
// dct_error("REF", 1, idct, odivx_idct_c);
Index: ffmpeg/libavcodec/fft-test.c
===================================================================
--- ffmpeg.orig/libavcodec/fft-test.c 2007-03-22 01:00:48.000000000 -0400
+++ ffmpeg/libavcodec/fft-test.c 2007-03-22 01:20:53.000000000 -0400
@@ -28,6 +28,9 @@
#include <unistd.h>
#include <sys/time.h>
+#undef fprintf
+#undef printf
+
int mm_flags;
/* reference fft */
there is no *printf in fft-test.c
and ive not checked that the other undefs are needed but that must be checked
before such changes can be accpeted also teh question remains why
HAVE_AV_CONFIG_H is defined at all for these files

[...]
Post by Ronald S. Bultje
Index: ffmpeg/libavcodec/i386/fdct_mmx.c
===================================================================
--- ffmpeg.orig/libavcodec/i386/fdct_mmx.c 2007-03-22 01:00:40.000000000 -0400
+++ ffmpeg/libavcodec/i386/fdct_mmx.c 2007-05-20 12:02:36.000000000 -0400
@@ -281,6 +281,13 @@
#define C6 12299
#define C7 6270
TABLE_SSE2
+#undef C1
+#undef C2
+#undef C3
+#undef C4
+#undef C5
+#undef C6
+#undef C7
}};
these dont seem to be #defined after the undef so what is this good for?

[...]
Post by Ronald S. Bultje
Index: ffmpeg/libavcodec/imgresample.c
===================================================================
--- ffmpeg.orig/libavcodec/imgresample.c 2007-03-22 01:00:47.000000000 -0400
+++ ffmpeg/libavcodec/imgresample.c 2007-03-22 01:20:53.000000000 -0400
@@ -28,8 +28,10 @@
#include "swscale.h"
#include "dsputil.h"
-#ifdef USE_FASTMEMCPY
-#include "libvo/fastmemcpy.h"
+#ifdef TEST
+#undef printf
+#undef fprintf
+#define av_log(p,l,...) fprintf(stderr,__VA_ARGS__)
ugly
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras
Ronald S. Bultje
2007-05-21 13:40:19 UTC
Permalink
Hi,
Post by Michael Niedermayer
[...]
Post by Ronald S. Bultje
Anyway, on to the relevant part of the patch for you. Attached, or if
that doesn't work on
http://people.freedesktop.org/~rbultje/ffmpeg_nommx.patch (still
testing...), you'll find those parts of the patch that you referenced
that I should submit separately. The patch does a bunch of things. First
of all, the gains: it allows most of the tests to be compiled (by
* most tests don't link to lav[ufc] and thus don't use av_log() but
printf(). However, for utility macros, they do include avutil.h, and
thus fail to compile b/c of the redefinition of av_log(). Thus, most
tests need a #undef printf/fprintf to compile. Similar for malloc in
swscale (last part of the patch).
* several tests reference mmx/gpl code w/o checking for whether this is
enabled. Those parts have been marked with appropriate compile
conditionals.
* as Mans suggested, emms -> emms_c
* in dsputil.c and dsputil_mmx.c/h264dsp_mmx.c, macros with the same
names are used. dsptest.c in tests/ includes both of those, and thus the
compile will give warnings. It's probably a good idea to #undef each of
them or use similar names. Both already use #undefs internally several
times for those variables (e.g. C[0-7]), since they're reused in various
places with different values within the same files. I simply added
#undefs at the end of where they're used also, so that multiple files
can use the same macro names. H264_{WEIGHT,MC} same story.
* fastmemcpy buggage, see above, remove if unwanted (I don't care if it
goes upstream, but I'll leave it in in my copy regardless).
* motion_test.c and dsptest.c had various API changes and I updated it
for those API changes. Worksforme[tm].
It's various changes together, but all of it is needed to make the tests
work, hence one big patch.
split it :)
Ok, how? I can submit several parts for the emms->emms_c, HAVE_GPL
changes, those are very small, then the rest of the HAVE_MMX stuff and
then API changes in various tests?

I took your comments for dct-test.c into account (less changes and not
Post by Michael Niedermayer
Post by Ronald S. Bultje
Index: ffmpeg/libavcodec/fft-test.c
===================================================================
--- ffmpeg.orig/libavcodec/fft-test.c 2007-03-22 01:00:48.000000000 -0400
+++ ffmpeg/libavcodec/fft-test.c 2007-03-22 01:20:53.000000000 -0400
@@ -28,6 +28,9 @@
#include <unistd.h>
#include <sys/time.h>
+#undef fprintf
+#undef printf
+
int mm_flags;
/* reference fft */
there is no *printf in fft-test.c
and ive not checked that the other undefs are needed but that must be checked
before such changes can be accpeted also teh question remains why
HAVE_AV_CONFIG_H is defined at all for these files
In file included from dct-test.c:33:
dsputil.h: In function 'copy_block2':
dsputil.h:688: warning: implicit declaration of function 'ST16'
dsputil.h:688: warning: implicit declaration of function 'LD16'
dsputil.h: In function 'copy_block4':
dsputil.h:699: warning: implicit declaration of function 'ST32'
dsputil.h:699: warning: implicit declaration of function 'LD32'
dct-test.c: In function 'idct248_ref':
dct-test.c:333: warning: implicit declaration of function 'sqrt'
dct-test.c:333: warning: incompatible implicit declaration of built-in
function 'sqrt'
dct-test.c:334: warning: implicit declaration of function 'cos'
dct-test.c:334: warning: incompatible implicit declaration of built-in
function 'cos'
dct-test.c:334: error: 'M_PI' undeclared (first use in this function)
dct-test.c:334: error: (Each undeclared identifier is reported only once
dct-test.c:334: error: for each function it appears in.)
dct-test.c:342: warning: incompatible implicit declaration of built-in
function 'sqrt'
dct-test.c:343: warning: incompatible implicit declaration of built-in
function 'cos'
dct-test.c:350: warning: incompatible implicit declaration of built-in
function 'sqrt'
dct-test.c:393: warning: implicit declaration of function 'rint'
dct-test.c:393: warning: incompatible implicit declaration of built-in
function 'rint'

I can work around this by adding an include for math.h.

In file included from fft-test.c:26:
dsputil.h: In function 'copy_block2':
dsputil.h:688: warning: implicit declaration of function 'ST16'
dsputil.h:688: warning: implicit declaration of function 'LD16'
dsputil.h: In function 'copy_block4':
dsputil.h:699: warning: implicit declaration of function 'ST32'
dsputil.h:699: warning: implicit declaration of function 'LD32'
fft-test.c: In function 'frandom':
fft-test.c:129: warning: implicit declaration of function 'random'
fft-test.c: In function 'help':
fft-test.c:161: warning: implicit declaration of function 'exit'
fft-test.c:161: warning: incompatible implicit declaration of built-in
function 'exit'
fft-test.c: In function 'main':
fft-test.c:198: warning: implicit declaration of function 'atoi'
fft-test.c:249: warning: implicit declaration of function 'memcpy'
fft-test.c:249: warning: incompatible implicit declaration of built-in
function 'memcpy'
fft-test.c:276: warning: incompatible implicit declaration of built-in
function 'memcpy'

I can work around this by adding includes for stdlib.h and string.h to
fft-test.c.

apiexample / motion_test give the dsputil warnings for ST/LD16/32 but
compile fine otherwise. I don't really know how to prevent the warnings,
since dsputil.h is clearly a file that is internal and supposed to be
used only internally (or well, such is my impression). So the fact that
it used internal API seems normal. You probably don't want to obfuscate
it with all sort of #ifdef HAVE_AV_CONFIG_H, do you? (I mean, I can just
protect all copy_blockx() functions with it to make the warnings go
away, but that's not a good idea.)

libswscale's cs_test compiles fine without, so removed that also. For
all of the above, I could remove it.

dsptest in tests/ and cputest in lavc/i386/ can't be compiled, since
they use internaly API (dsptest is about ten pages of warnings, so
nevermind there), cputest is below:

cputest.c: In function 'mm_support':
cputest.c:83: error: 'MM_MMX' undeclared (first use in this function)
cputest.c:83: error: (Each undeclared identifier is reported only once
cputest.c:83: error: for each function it appears in.)
cputest.c:85: error: 'MM_MMXEXT' undeclared (first use in this function)
cputest.c:85: error: 'MM_SSE' undeclared (first use in this function)
cputest.c:87: error: 'MM_SSE2' undeclared (first use in this function)
cputest.c:89: error: 'MM_SSE3' undeclared (first use in this function)
cputest.c:91: error: 'MM_SSSE3' undeclared (first use in this function)
cputest.c:99: error: 'MM_3DNOW' undeclared (first use in this function)
cputest.c:101: error: 'MM_3DNOWEXT' undeclared (first use in this
function)
cputest.c: In function 'main':
cputest.c:128: warning: implicit declaration of function 'printf'
cputest.c:128: warning: incompatible implicit declaration of built-in
function 'printf'

I left those as-is.
Post by Michael Niedermayer
Post by Ronald S. Bultje
Index: ffmpeg/libavcodec/i386/fdct_mmx.c
===================================================================
--- ffmpeg.orig/libavcodec/i386/fdct_mmx.c 2007-03-22 01:00:40.000000000 -0400
+++ ffmpeg/libavcodec/i386/fdct_mmx.c 2007-05-20 12:02:36.000000000 -0400
@@ -281,6 +281,13 @@
#define C6 12299
#define C7 6270
TABLE_SSE2
+#undef C1
+#undef C2
+#undef C3
+#undef C4
+#undef C5
+#undef C6
+#undef C7
}};
these dont seem to be #defined after the undef so what is this good for?
dsptest.c includes several .c files, each of which has these macros
without undef'ing them the first time, i.e. assuming they're yet
undeclared. This means if you include two such files, the second causes
warnings because of redeclarations of all of those variables. undef'ing
them at the end of the source file seems the right thing to do, at least
in one of them. The same is true for the undef of the dspfunc, H264_MC
and H264_WEIGHT elsewhere also. They all cause compile problems in
dcttest.c.
Post by Michael Niedermayer
Post by Ronald S. Bultje
Index: ffmpeg/libavcodec/imgresample.c
===================================================================
--- ffmpeg.orig/libavcodec/imgresample.c 2007-03-22 01:00:47.000000000 -0400
+++ ffmpeg/libavcodec/imgresample.c 2007-03-22 01:20:53.000000000 -0400
@@ -28,8 +28,10 @@
#include "swscale.h"
#include "dsputil.h"
-#ifdef USE_FASTMEMCPY
-#include "libvo/fastmemcpy.h"
+#ifdef TEST
+#undef printf
+#undef fprintf
+#define av_log(p,l,...) fprintf(stderr,__VA_ARGS__)
ugly
This is old, actually, I think imgresample.c is no longer used. This can
probably be removed.

For reference, new patch attached. If you like it, I'll split it in
whatever way you prefer and submit parts.

Ronald
Index: ffmpeg/libavcodec/dct-test.c
===================================================================
--- ffmpeg.orig/libavcodec/dct-test.c 2007-03-22 01:00:46.000000000 -0400
+++ ffmpeg/libavcodec/dct-test.c 2007-05-21 09:28:31.000000000 -0400
@@ -29,6 +29,7 @@
#include <string.h>
#include <sys/time.h>
#include <unistd.h>
+#include <math.h>

#include "dsputil.h"

@@ -39,8 +40,6 @@
#define MAX(a, b) (((a) > (b)) ? (a) : (b))
#endif

-#undef printf
-
void *fast_memcpy(void *a, const void *b, size_t c){return memcpy(a,b,c);};

/* reference fdct/idct */
@@ -162,6 +161,11 @@
for(i=0; i<64; i++)
block_org[i]= block1[i];

+#ifndef HAVE_MMX
+#define ff_mmx_idct NULL
+#define ff_mmxext_idct NULL
+#define ff_simple_idct_mmx NULL
+#endif
if (fdct_func == ff_mmx_idct ||
fdct_func == j_rev_dct || fdct_func == ff_mmxext_idct) {
for(i=0;i<64;i++)
@@ -169,7 +173,6 @@
} else if(fdct_func == ff_simple_idct_mmx ) {
for(i=0;i<64;i++)
block[idct_simple_mmx_perm[i]] = block1[i];
-
} else {
for(i=0; i<64; i++)
block[i]= block1[i];
@@ -184,7 +187,7 @@
#endif

fdct_func(block);
- emms(); /* for ff_mmx_idct */
+ emms_c(); /* for ff_mmx_idct */

if (fdct_func == fdct_ifast
#ifndef FAAN_POSTSCALE
@@ -286,7 +289,7 @@
it1 += NB_ITS_SPEED;
ti1 = gettime() - ti;
} while (ti1 < 1000000);
- emms();
+ emms_c();

printf("%s %s: %0.1f kdct/s\n",
is_idct ? "IDCT" : "DCT",
@@ -446,7 +449,7 @@
it1 += NB_ITS_SPEED;
ti1 = gettime() - ti;
} while (ti1 < 1000000);
- emms();
+ emms_c();

printf("%s %s: %0.1f kdct/s\n",
1 ? "IDCT248" : "DCT248",
@@ -508,18 +511,24 @@
dct_error("REF-DBL", 0, fdct, fdct, test); /* only to verify code ! */
dct_error("IJG-AAN-INT", 0, fdct_ifast, fdct, test);
dct_error("IJG-LLM-INT", 0, ff_jpeg_fdct_islow, fdct, test);
+#ifdef HAVE_MMX
dct_error("MMX", 0, ff_fdct_mmx, fdct, test);
dct_error("MMX2", 0, ff_fdct_mmx2, fdct, test);
+#endif
dct_error("FAAN", 0, ff_faandct, fdct, test);
} else {
dct_error("REF-DBL", 1, idct, idct, test);
dct_error("INT", 1, j_rev_dct, idct, test);
+ dct_error("SIMPLE-C", 1, simple_idct, idct, test);
+#ifdef HAVE_MMX
dct_error("LIBMPEG2-MMX", 1, ff_mmx_idct, idct, test);
dct_error("LIBMPEG2-MMXEXT", 1, ff_mmxext_idct, idct, test);
- dct_error("SIMPLE-C", 1, simple_idct, idct, test);
dct_error("SIMPLE-MMX", 1, ff_simple_idct_mmx, idct, test);
+#ifdef CONFIG_GPL
dct_error("XVID-MMX", 1, ff_idct_xvid_mmx, idct, test);
dct_error("XVID-MMX2", 1, ff_idct_xvid_mmx2, idct, test);
+#endif /* CONFIG_GPL */
+#endif /* HAVE_MMX */
// dct_error("ODIVX-C", 1, odivx_idct_c, idct);
//printf(" test against odivx idct\n");
// dct_error("REF", 1, idct, odivx_idct_c);
Index: ffmpeg/libavcodec/fft-test.c
===================================================================
--- ffmpeg.orig/libavcodec/fft-test.c 2007-03-22 01:00:48.000000000 -0400
+++ ffmpeg/libavcodec/fft-test.c 2007-05-21 09:13:59.000000000 -0400
@@ -27,6 +27,8 @@
#include <math.h>
#include <unistd.h>
#include <sys/time.h>
+#include <stdlib.h>
+#include <string.h>

int mm_flags;

Index: ffmpeg/libavcodec/i386/cputest.c
===================================================================
--- ffmpeg.orig/libavcodec/i386/cputest.c 2007-03-22 01:00:40.000000000 -0400
+++ ffmpeg/libavcodec/i386/cputest.c 2007-03-22 01:20:53.000000000 -0400
@@ -120,6 +120,7 @@
}

#ifdef __TEST__
+#undef printf
int main ( void )
{
int mm_flags;
Index: ffmpeg/libavcodec/i386/dsputil_mmx.c
===================================================================
--- ffmpeg.orig/libavcodec/i386/dsputil_mmx.c 2007-03-22 01:00:40.000000000 -0400
+++ ffmpeg/libavcodec/i386/dsputil_mmx.c 2007-05-20 @@ -3457,6 +3457,7 @@
dspfunc(put_2tap_qpel, 1, 8);
dspfunc(avg_2tap_qpel, 0, 16);
dspfunc(avg_2tap_qpel, 1, 8);
+#undef dspfunc

c->avg_h264_chroma_pixels_tab[0]= avg_h264_chroma_mc8_3dnow;
c->avg_h264_chroma_pixels_tab[1]= avg_h264_chroma_mc4_3dnow;
Index: ffmpeg/libavcodec/i386/fdct_mmx.c
===================================================================
--- ffmpeg.orig/libavcodec/i386/fdct_mmx.c 2007-03-22 01:00:40.000000000 -0400
+++ ffmpeg/libavcodec/i386/fdct_mmx.c 2007-05-20 12:02:36.000000000 -0400
@@ -281,6 +281,13 @@
#define C6 12299
#define C7 6270
TABLE_SSE2
+#undef C1
+#undef C2
+#undef C3
+#undef C4
+#undef C5
+#undef C6
+#undef C7
}};


Index: ffmpeg/libavcodec/i386/simple_idct_mmx.c
===================================================================
--- ffmpeg.orig/libavcodec/i386/simple_idct_mmx.c 2007-03-22 01:00:40.000000000 -0400
+++ ffmpeg/libavcodec/i386/simple_idct_mmx.c 2007-05-20 12:09:00.000000000 -0400
@@ -77,6 +77,14 @@

C7, -C5, C7, -C5,
C3, -C1, C3, -C1
+#undef C0
+#undef C1
+#undef C2
+#undef C3
+#undef C4
+#undef C5
+#undef C6
+#undef C7
};

#if 0
@@ -87,14 +95,6 @@

static void inline idctCol (int16_t * col, int16_t *input)
{
-#undef C0
-#undef C1
-#undef C2
-#undef C3
-#undef C4
-#undef C5
-#undef C6
-#undef C7
int a0, a1, a2, a3, b0, b1, b2, b3;
const int C0 = 23170; //cos(i*M_PI/16)*sqrt(2)*(1<<14) + 0.5
const int C1 = 22725; //cos(i*M_PI/16)*sqrt(2)*(1<<14) + 0.5
Index: ffmpeg/libavcodec/motion_test.c
===================================================================
--- ffmpeg.orig/libavcodec/motion_test.c 2007-03-22 01:00:50.000000000 -0400
+++ ffmpeg/libavcodec/motion_test.c 2007-05-21 09:06:35.000000000 -0400
@@ -31,24 +31,24 @@

#include "dsputil.h"

+#ifdef HAVE_MMX
#include "i386/mmx.h"
+#endif

-#undef printf
-
-int pix_abs16x16_mmx(uint8_t *blk1, uint8_t *blk2, int lx);
-int pix_abs16x16_mmx1(uint8_t *blk1, uint8_t *blk2, int lx);
-int pix_abs16x16_c(uint8_t *blk1, uint8_t *blk2, int lx);
-int pix_abs16x16_x2_mmx(uint8_t *blk1, uint8_t *blk2, int lx);
-int pix_abs16x16_x2_mmx1(uint8_t *blk1, uint8_t *blk2, int lx);
-int pix_abs16x16_x2_c(uint8_t *blk1, uint8_t *blk2, int lx);
-int pix_abs16x16_y2_mmx(uint8_t *blk1, uint8_t *blk2, int lx);
-int pix_abs16x16_y2_mmx1(uint8_t *blk1, uint8_t *blk2, int lx);
-int pix_abs16x16_y2_c(uint8_t *blk1, uint8_t *blk2, int lx);
-int pix_abs16x16_xy2_mmx(uint8_t *blk1, uint8_t *blk2, int lx);
-int pix_abs16x16_xy2_mmx1(uint8_t *blk1, uint8_t *blk2, int lx);
-int pix_abs16x16_xy2_c(uint8_t *blk1, uint8_t *blk2, int lx);
+int pix_abs16x16_mmx(void *v, uint8_t *blk1, uint8_t *blk2, int lx, int h);
+int pix_abs16x16_mmx1(void *v, uint8_t *blk1, uint8_t *blk2, int lx, int h);
+int pix_abs16x16_c(void *v, uint8_t *blk1, uint8_t *blk2, int lx, int h);
+int pix_abs16x16_x2_mmx(void *v, uint8_t *blk1, uint8_t *blk2, int lx, int h);
+int pix_abs16x16_x2_mmx1(void *v, uint8_t *blk1, uint8_t *blk2, int lx, int h);
+int pix_abs16x16_x2_c(void *v, uint8_t *blk1, uint8_t *blk2, int lx, int h);
+int pix_abs16x16_y2_mmx(void *v, uint8_t *blk1, uint8_t *blk2, int lx, int h);
+int pix_abs16x16_y2_mmx1(void *v, uint8_t *blk1, uint8_t *blk2, int lx, int h);
+int pix_abs16x16_y2_c(void *v, uint8_t *blk1, uint8_t *blk2, int lx, int h);
+int pix_abs16x16_xy2_mmx(void *v, uint8_t *blk1, uint8_t *blk2, int lx, int h);
+int pix_abs16x16_xy2_mmx1(void *v, uint8_t *blk1, uint8_t *blk2, int lx, int h);
+int pix_abs16x16_xy2_c(void *v, uint8_t *blk1, uint8_t *blk2, int lx, int h);

-typedef int motion_func(uint8_t *blk1, uint8_t *blk2, int lx);
+typedef int motion_func(void *v, uint8_t *blk1, uint8_t *blk2, int lx, int h);

#define WIDTH 64
#define HEIGHT 64
@@ -103,15 +103,15 @@
for(y=0;y<HEIGHT-17;y++) {
for(x=0;x<WIDTH-17;x++) {
ptr = img2 + y * WIDTH + x;
- d1 = test_func(img1, ptr, WIDTH);
- d2 = ref_func(img1, ptr, WIDTH);
+ d1 = test_func(NULL, img1, ptr, WIDTH, 1);
+ d2 = ref_func(NULL, img1, ptr, WIDTH, 1);
if (d1 != d2) {
printf("error: mmx=%d c=%d\n", d1, d2);
}
}
}
}
- emms();
+ emms_c();

/* speed test */
ti = gettime();
@@ -120,11 +120,11 @@
for(y=0;y<HEIGHT-17;y++) {
for(x=0;x<WIDTH-17;x++) {
ptr = img2 + y * WIDTH + x;
- d1 += test_func(img1, ptr, WIDTH);
+ d1 += test_func(NULL, img1, ptr, WIDTH, 1);
}
}
}
- emms();
+ emms_c();
dummy = d1; /* avoid optimisation */
ti = gettime() - ti;

@@ -136,13 +136,17 @@

int main(int argc, char **argv)
{
- int c;
+ int n;
+#ifdef HAVE_MMX
+ AVCodecContext *ctx;
+ DSPContext c, mmx;
+#endif

for(;;) {
- c = getopt(argc, argv, "h");
- if (c == -1)
+ n = getopt(argc, argv, "h");
+ if (n == -1)
break;
- switch(c) {
+ switch(n) {
case 'h':
help();
break;
@@ -151,9 +155,25 @@

printf("ffmpeg motion test\n");

- test_motion("mmx", pix_abs16x16_mmx, pix_abs16x16_c);
- test_motion("mmx_x2", pix_abs16x16_x2_mmx, pix_abs16x16_x2_c);
- test_motion("mmx_y2", pix_abs16x16_y2_mmx, pix_abs16x16_y2_c);
- test_motion("mmx_xy2", pix_abs16x16_xy2_mmx, pix_abs16x16_xy2_c);
+#ifdef HAVE_MMX
+ ctx = avcodec_alloc_context();
+ mm_flags = 0;
+ dsputil_init(&c, ctx);
+ mm_flags = MM_MMX;
+ dsputil_init(&mmx, ctx);
+
+ test_motion("mmx/16", mmx.pix_abs[0][0], c.pix_abs[0][0]);
+ test_motion("mmx_x2/16", mmx.pix_abs[0][1], c.pix_abs[0][1]);
+ test_motion("mmx_y2/16", mmx.pix_abs[0][2], c.pix_abs[0][2]);
+ test_motion("mmx_xy2/16", mmx.pix_abs[0][3], c.pix_abs[0][3]);
+
+ test_motion("mmx/8", mmx.pix_abs[1][0], c.pix_abs[1][0]);
+ test_motion("mmx_x2/8", mmx.pix_abs[1][1], c.pix_abs[1][1]);
+ test_motion("mmx_y2/8", mmx.pix_abs[1][2], c.pix_abs[1][2]);
+ test_motion("mmx_xy2/8", mmx.pix_abs[1][3], c.pix_abs[1][3]);
+
+ av_free(ctx);
+#endif
+
return 0;
}
Index: ffmpeg/libavformat/grab.c
===================================================================
--- ffmpeg.orig/libavformat/grab.c 2007-03-22 01:00:54.000000000 -0400
+++ ffmpeg/libavformat/grab.c 2007-05-20 12:55:11.000000000 -0400
@@ -846,9 +846,7 @@
DEINT_LINE_LUM(12)
}
}
-#ifdef HAVE_MMX
- emms();
-#endif
+ emms_c();
return s->frame_size;
}

Index: ffmpeg/tests/dsptest.c
===================================================================
--- ffmpeg.orig/tests/dsptest.c 2007-03-22 01:00:52.000000000 -0400
+++ ffmpeg/tests/dsptest.c 2007-05-20 12:50:47.000000000 -0400
@@ -20,18 +20,18 @@
#include "avcodec.h"
#include "dsputil.h"
#include "mpegvideo.h"
-#include "mpeg12data.h"
-#include "mpeg4data.h"
-#include "../libavcodec/i386/cputest.c"
-#include "../libavcodec/i386/dsputil_mmx.c"
-
-#include "../libavcodec/i386/fdct_mmx.c"
-#include "../libavcodec/i386/idct_mmx.c"
-#include "../libavcodec/i386/motion_est_mmx.c"
-#include "../libavcodec/i386/simple_idct_mmx.c"
-#include "../libavcodec/dsputil.c"
-#include "../libavcodec/simple_idct.c"
-#include "../libavcodec/jfdctfst.c"
+//#include "mpeg12data.h"
+//#include "mpeg4data.h"
+#include "i386/cputest.c"
+#include "i386/dsputil_mmx.c"
+
+#include "i386/fdct_mmx.c"
+#include "i386/idct_mmx.c"
+#include "i386/motion_est_mmx.c"
+#include "i386/simple_idct_mmx.c"
+#include "dsputil.c"
+#include "simple_idct.c"
+#include "jfdctfst.c"

#undef TESTCPU_MAIN

@@ -73,27 +73,27 @@
int mm_flags;
} pix_func[] = {

- PIX_FUNC_MMX(put_pixels),
+ PIX_FUNC_MMX(put_pixels8),
//PIX_FUNC_MMX(get_pixels),
//PIX_FUNC_MMX(put_pixels_clamped),
#if 1
- PIX_FUNC(put_pixels_x2),
- PIX_FUNC(put_pixels_y2),
- PIX_FUNC_MMX(put_pixels_xy2),
-
- PIX_FUNC(put_no_rnd_pixels_x2),
- PIX_FUNC(put_no_rnd_pixels_y2),
- PIX_FUNC_MMX(put_no_rnd_pixels_xy2),
-
- PIX_FUNC(avg_pixels),
- PIX_FUNC(avg_pixels_x2),
- PIX_FUNC(avg_pixels_y2),
- PIX_FUNC(avg_pixels_xy2),
-
- PIX_FUNC_MMX(avg_no_rnd_pixels),
- PIX_FUNC_MMX(avg_no_rnd_pixels_x2),
- PIX_FUNC_MMX(avg_no_rnd_pixels_y2),
- PIX_FUNC_MMX(avg_no_rnd_pixels_xy2),
+ PIX_FUNC(put_pixels8_x2),
+ PIX_FUNC(put_pixels8_y2),
+ PIX_FUNC_MMX(put_pixels8_xy2),
+
+ PIX_FUNC(put_no_rnd_pixels8_x2),
+ PIX_FUNC(put_no_rnd_pixels8_y2),
+ PIX_FUNC_MMX(put_no_rnd_pixels8_xy2),
+
+ PIX_FUNC(avg_pixels8),
+ PIX_FUNC(avg_pixels8_x2),
+ PIX_FUNC(avg_pixels8_y2),
+ PIX_FUNC(avg_pixels8_xy2),
+
+ PIX_FUNC_MMX(avg_no_rnd_pixels8),
+ PIX_FUNC_MMX(avg_no_rnd_pixels8_x2),
+ PIX_FUNC_MMX(avg_no_rnd_pixels8_y2),
+ PIX_FUNC_MMX(avg_no_rnd_pixels8_xy2),
#endif
{ 0, 0 }
};
Index: ffmpeg/libavcodec/i386/h264dsp_mmx.c
===================================================================
--- ffmpeg.orig/libavcodec/i386/h264dsp_mmx.c 2007-03-22 01:00:40.000000000 -0400
+++ ffmpeg/libavcodec/i386/h264dsp_mmx.c 2007-05-20 12:13:28.000000000 -0400
@@ -1374,7 +1374,7 @@
H264_MC(avg_, 4, mmx2)
H264_MC(avg_, 8, mmx2)
H264_MC(avg_, 16,mmx2)
-
+#undef H264_MC

#define H264_CHROMA_OP(S,D)
#define H264_CHROMA_OP4(S,D,T)
@@ -1514,4 +1514,4 @@
H264_WEIGHT( 4, 8)
H264_WEIGHT( 4, 4)
H264_WEIGHT( 4, 2)
-
+#undef H264_WEIGHT
Index: ffmpeg/libswscale/rgb2rgb.c
===================================================================
--- ffmpeg.orig/libswscale/rgb2rgb.c 2007-03-22 01:00:59.000000000 -0400
+++ ffmpeg/libswscale/rgb2rgb.c 2007-03-22 01:20:53.000000000 -0400
@@ -33,9 +33,6 @@
#include "swscale_internal.h"
#include "x86_cpu.h"
#include "bswap.h"
-#ifdef USE_FASTMEMCPY
-#include "libvo/fastmemcpy.h"
-#endif

#define FAST_BGR2YV12 // use 7 bit coeffs instead of 15bit

Index: ffmpeg/libswscale/cs_test.c
===================================================================
--- ffmpeg.orig/libswscale/cs_test.c 2007-03-22 01:00:59.000000000 -0400
+++ ffmpeg/libswscale/cs_test.c 2007-05-21 09:08:34.000000000 -0400
@@ -23,7 +23,9 @@
#include <unistd.h>
#include <stdlib.h>
#include <inttypes.h>
+#ifdef HAVE_MALLOC_H
#include <malloc.h>
+#endif

#include "swscale.h"
#include "rgb2rgb.h"
Michael Niedermayer
2007-05-21 17:13:40 UTC
Permalink
Hi
Post by Ronald S. Bultje
Hi,
Post by Michael Niedermayer
[...]
Post by Ronald S. Bultje
Anyway, on to the relevant part of the patch for you. Attached, or if
that doesn't work on
http://people.freedesktop.org/~rbultje/ffmpeg_nommx.patch (still
testing...), you'll find those parts of the patch that you referenced
that I should submit separately. The patch does a bunch of things. First
of all, the gains: it allows most of the tests to be compiled (by
* most tests don't link to lav[ufc] and thus don't use av_log() but
printf(). However, for utility macros, they do include avutil.h, and
thus fail to compile b/c of the redefinition of av_log(). Thus, most
tests need a #undef printf/fprintf to compile. Similar for malloc in
swscale (last part of the patch).
* several tests reference mmx/gpl code w/o checking for whether this is
enabled. Those parts have been marked with appropriate compile
conditionals.
* as Mans suggested, emms -> emms_c
* in dsputil.c and dsputil_mmx.c/h264dsp_mmx.c, macros with the same
names are used. dsptest.c in tests/ includes both of those, and thus the
compile will give warnings. It's probably a good idea to #undef each of
them or use similar names. Both already use #undefs internally several
times for those variables (e.g. C[0-7]), since they're reused in various
places with different values within the same files. I simply added
#undefs at the end of where they're used also, so that multiple files
can use the same macro names. H264_{WEIGHT,MC} same story.
* fastmemcpy buggage, see above, remove if unwanted (I don't care if it
goes upstream, but I'll leave it in in my copy regardless).
* motion_test.c and dsptest.c had various API changes and I updated it
for those API changes. Worksforme[tm].
It's various changes together, but all of it is needed to make the tests
work, hence one big patch.
split it :)
Ok, how?
so that no 2 unrelated changes are in 1 patch, emms->emms_c and
HAVE_GPL for example are unrelated
Post by Ronald S. Bultje
I can submit several parts for the emms->emms_c, HAVE_GPL
changes, those are very small, then the rest of the HAVE_MMX stuff and
then API changes in various tests?
I took your comments for dct-test.c into account (less changes and not
Post by Michael Niedermayer
Post by Ronald S. Bultje
Index: ffmpeg/libavcodec/fft-test.c
===================================================================
--- ffmpeg.orig/libavcodec/fft-test.c 2007-03-22 01:00:48.000000000 -0400
+++ ffmpeg/libavcodec/fft-test.c 2007-03-22 01:20:53.000000000 -0400
@@ -28,6 +28,9 @@
#include <unistd.h>
#include <sys/time.h>
+#undef fprintf
+#undef printf
+
int mm_flags;
/* reference fft */
there is no *printf in fft-test.c
and ive not checked that the other undefs are needed but that must be checked
before such changes can be accpeted also teh question remains why
HAVE_AV_CONFIG_H is defined at all for these files
dsputil.h:688: warning: implicit declaration of function 'ST16'
dsputil.h:688: warning: implicit declaration of function 'LD16'
dsputil.h:699: warning: implicit declaration of function 'ST32'
dsputil.h:699: warning: implicit declaration of function 'LD32'
dct-test.c:333: warning: implicit declaration of function 'sqrt'
dct-test.c:333: warning: incompatible implicit declaration of built-in
function 'sqrt'
dct-test.c:334: warning: implicit declaration of function 'cos'
dct-test.c:334: warning: incompatible implicit declaration of built-in
function 'cos'
dct-test.c:334: error: 'M_PI' undeclared (first use in this function)
dct-test.c:334: error: (Each undeclared identifier is reported only once
dct-test.c:334: error: for each function it appears in.)
dct-test.c:342: warning: incompatible implicit declaration of built-in
function 'sqrt'
dct-test.c:343: warning: incompatible implicit declaration of built-in
function 'cos'
dct-test.c:350: warning: incompatible implicit declaration of built-in
function 'sqrt'
dct-test.c:393: warning: implicit declaration of function 'rint'
dct-test.c:393: warning: incompatible implicit declaration of built-in
function 'rint'
I can work around this by adding an include for math.h.
dsputil.h:688: warning: implicit declaration of function 'ST16'
dsputil.h:688: warning: implicit declaration of function 'LD16'
dsputil.h:699: warning: implicit declaration of function 'ST32'
dsputil.h:699: warning: implicit declaration of function 'LD32'
fft-test.c:129: warning: implicit declaration of function 'random'
fft-test.c:161: warning: implicit declaration of function 'exit'
fft-test.c:161: warning: incompatible implicit declaration of built-in
function 'exit'
fft-test.c:198: warning: implicit declaration of function 'atoi'
fft-test.c:249: warning: implicit declaration of function 'memcpy'
fft-test.c:249: warning: incompatible implicit declaration of built-in
function 'memcpy'
fft-test.c:276: warning: incompatible implicit declaration of built-in
function 'memcpy'
I can work around this by adding includes for stdlib.h and string.h to
fft-test.c.
apiexample / motion_test give the dsputil warnings for ST/LD16/32 but
compile fine otherwise. I don't really know how to prevent the warnings,
since dsputil.h is clearly a file that is internal and supposed to be
used only internally (or well, such is my impression). So the fact that
it used internal API seems normal. You probably don't want to obfuscate
it with all sort of #ifdef HAVE_AV_CONFIG_H, do you?
no
Post by Ronald S. Bultje
(I mean, I can just
protect all copy_blockx() functions with it to make the warnings go
away, but that's not a good idea.)
libswscale's cs_test compiles fine without, so removed that also. For
all of the above, I could remove it.
the more of the test utils work without HAVE_AV_CONFIG_H the better
messing with the internal API is never a good idea if it can be
avoided, they also would serve as a bad example on how to use lavc
Post by Ronald S. Bultje
dsptest in tests/ and cputest in lavc/i386/ can't be compiled, since
they use internaly API (dsptest is about ten pages of warnings, so
cputest.c:83: error: 'MM_MMX' undeclared (first use in this function)
cputest.c:83: error: (Each undeclared identifier is reported only once
cputest.c:83: error: for each function it appears in.)
cputest.c:85: error: 'MM_MMXEXT' undeclared (first use in this function)
cputest.c:85: error: 'MM_SSE' undeclared (first use in this function)
cputest.c:87: error: 'MM_SSE2' undeclared (first use in this function)
cputest.c:89: error: 'MM_SSE3' undeclared (first use in this function)
cputest.c:91: error: 'MM_SSSE3' undeclared (first use in this function)
cputest.c:99: error: 'MM_3DNOW' undeclared (first use in this function)
cputest.c:101: error: 'MM_3DNOWEXT' undeclared (first use in this
function)
this should be useing FF_MM_MMX and similar
Post by Ronald S. Bultje
cputest.c:128: warning: implicit declaration of function 'printf'
cputest.c:128: warning: incompatible implicit declaration of built-in
function 'printf'
I left those as-is.
Post by Michael Niedermayer
Post by Ronald S. Bultje
Index: ffmpeg/libavcodec/i386/fdct_mmx.c
===================================================================
--- ffmpeg.orig/libavcodec/i386/fdct_mmx.c 2007-03-22 01:00:40.000000000 -0400
+++ ffmpeg/libavcodec/i386/fdct_mmx.c 2007-05-20 12:02:36.000000000 -0400
@@ -281,6 +281,13 @@
#define C6 12299
#define C7 6270
TABLE_SSE2
+#undef C1
+#undef C2
+#undef C3
+#undef C4
+#undef C5
+#undef C6
+#undef C7
}};
these dont seem to be #defined after the undef so what is this good for?
dsptest.c includes several .c files, each of which has these macros
without undef'ing them the first time, i.e. assuming they're yet
undeclared. This means if you include two such files, the second causes
warnings because of redeclarations of all of those variables. undef'ing
them at the end of the source file seems the right thing to do, at least
in one of them.
i disagree, the fact that dsptest.c #includes several random .c files
is the problem, hacking the c files to make that possible is not a good
solution

i guess i wouldnt be opposed to svn remove dsptest.c ...


[...]
Post by Ronald S. Bultje
For reference, new patch attached. If you like it, I'll split it in
whatever way you prefer and submit parts.
i like it in principle but the individual changes need to be reviewed
and ill do that after you submitted them in a splitted fashion as its
much easier

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

While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin
Diego Biurrun
2007-05-21 22:28:08 UTC
Permalink
Post by Michael Niedermayer
Post by Ronald S. Bultje
Post by Michael Niedermayer
Post by Ronald S. Bultje
--- ffmpeg.orig/libavcodec/i386/fdct_mmx.c 2007-03-22 01:00:40.000000000 -0400
+++ ffmpeg/libavcodec/i386/fdct_mmx.c 2007-05-20 12:02:36.000000000 -0400
@@ -281,6 +281,13 @@
#define C6 12299
#define C7 6270
TABLE_SSE2
+#undef C1
+#undef C2
+#undef C3
+#undef C4
+#undef C5
+#undef C6
+#undef C7
}};
these dont seem to be #defined after the undef so what is this good for?
dsptest.c includes several .c files, each of which has these macros
without undef'ing them the first time, i.e. assuming they're yet
undeclared. This means if you include two such files, the second causes
warnings because of redeclarations of all of those variables. undef'ing
them at the end of the source file seems the right thing to do, at least
in one of them.
i disagree, the fact that dsptest.c #includes several random .c files
is the problem, hacking the c files to make that possible is not a good
solution
i guess i wouldnt be opposed to svn remove dsptest.c ...
Did it outlive its usefulness? Then it should go ...

Diego
Michael Niedermayer
2007-05-21 23:48:10 UTC
Permalink
Hi
Post by Diego Biurrun
Post by Michael Niedermayer
Post by Ronald S. Bultje
Post by Michael Niedermayer
Post by Ronald S. Bultje
--- ffmpeg.orig/libavcodec/i386/fdct_mmx.c 2007-03-22 01:00:40.000000000 -0400
+++ ffmpeg/libavcodec/i386/fdct_mmx.c 2007-05-20 12:02:36.000000000 -0400
@@ -281,6 +281,13 @@
#define C6 12299
#define C7 6270
TABLE_SSE2
+#undef C1
+#undef C2
+#undef C3
+#undef C4
+#undef C5
+#undef C6
+#undef C7
}};
these dont seem to be #defined after the undef so what is this good for?
dsptest.c includes several .c files, each of which has these macros
without undef'ing them the first time, i.e. assuming they're yet
undeclared. This means if you include two such files, the second causes
warnings because of redeclarations of all of those variables. undef'ing
them at the end of the source file seems the right thing to do, at least
in one of them.
i disagree, the fact that dsptest.c #includes several random .c files
is the problem, hacking the c files to make that possible is not a good
solution
i guess i wouldnt be opposed to svn remove dsptest.c ...
Did it outlive its usefulness? Then it should go ...
well look at svn log dsptest.c, the last non cosmetic change was r613
i didnt even know that this file existed :)
it uses its own benchmarking code (which is x86 gcc specific, this wont
even compile anywhere else)
it only supports a very tiny subset of the dsp functions

so what IS it good for?

if i want to benchmark some code i put START/STOP timer around it
and see how fast that is, this is more representative than such a synthetic
benchmark
now if it would test all the functions in dsputil then i wouldnt complain
but it tests 15 of well count them, the h.264 motion compensation alone needs
over 100

so this file would need some serious work to become usefull, leaving it
as is and spreading hacks all over lavc to keep it compiling is giga stupid

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

Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin
Arpi
2007-05-21 23:54:00 UTC
Permalink
Hi,
Post by Michael Niedermayer
Post by Diego Biurrun
Post by Michael Niedermayer
i guess i wouldnt be opposed to svn remove dsptest.c ...
Did it outlive its usefulness? Then it should go ...
well look at svn log dsptest.c, the last non cosmetic change was r613
i didnt even know that this file existed :)
it uses its own benchmarking code (which is x86 gcc specific, this wont
even compile anywhere else)
it only supports a very tiny subset of the dsp functions
so what IS it good for?
it served as a "good" documentation on the dct functions and permutations
relations and usage for me, when i was experimenting with some new codec
ideas based on optimized ffmpeg functions...

anyway let it go, or maybe move it into DOCS/tech or examples/ :)

A'rpi
Michael Niedermayer
2007-05-22 01:50:36 UTC
Permalink
Hi
Post by Arpi
Hi,
Post by Michael Niedermayer
Post by Diego Biurrun
Post by Michael Niedermayer
i guess i wouldnt be opposed to svn remove dsptest.c ...
Did it outlive its usefulness? Then it should go ...
well look at svn log dsptest.c, the last non cosmetic change was r613
i didnt even know that this file existed :)
it uses its own benchmarking code (which is x86 gcc specific, this wont
even compile anywhere else)
it only supports a very tiny subset of the dsp functions
so what IS it good for?
it served as a "good" documentation on the dct functions and permutations
relations and usage for me, when i was experimenting with some new codec
ideas based on optimized ffmpeg functions...
hmm, it sounds a little like you are talking about libavcodec/dct-test.c
while iam talking about tests/dsptest.c whos existence i honestly
wasnt aware of until today :)
Post by Arpi
anyway let it go, or maybe move it into DOCS/tech or examples/ :)
if you think its usefull then ive no objections to moving it there or
leaving it where it is as long as we dont start hacking lavc because
dsptest.c does #include *.c more or less instead of properly linking
to the libs

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

There will always be a question for which you do not know the correct awnser.
Diego Biurrun
2007-05-22 07:16:55 UTC
Permalink
Post by Michael Niedermayer
Post by Arpi
Post by Michael Niedermayer
Post by Diego Biurrun
Post by Michael Niedermayer
i guess i wouldnt be opposed to svn remove dsptest.c ...
Did it outlive its usefulness? Then it should go ...
well look at svn log dsptest.c, the last non cosmetic change was r613
i didnt even know that this file existed :)
it uses its own benchmarking code (which is x86 gcc specific, this wont
even compile anywhere else)
it only supports a very tiny subset of the dsp functions
so what IS it good for?
it served as a "good" documentation on the dct functions and permutations
relations and usage for me, when i was experimenting with some new codec
ideas based on optimized ffmpeg functions...
hmm, it sounds a little like you are talking about libavcodec/dct-test.c
while iam talking about tests/dsptest.c whos existence i honestly
wasnt aware of until today :)
Same here, I kept confusing it with the one in libavcodec.

Diego
Diego Biurrun
2007-05-24 20:05:36 UTC
Permalink
Post by Diego Biurrun
Post by Michael Niedermayer
Post by Arpi
Post by Michael Niedermayer
Post by Diego Biurrun
Post by Michael Niedermayer
i guess i wouldnt be opposed to svn remove dsptest.c ...
Did it outlive its usefulness? Then it should go ...
well look at svn log dsptest.c, the last non cosmetic change was r613
i didnt even know that this file existed :)
it uses its own benchmarking code (which is x86 gcc specific, this wont
even compile anywhere else)
it only supports a very tiny subset of the dsp functions
so what IS it good for?
it served as a "good" documentation on the dct functions and permutations
relations and usage for me, when i was experimenting with some new codec
ideas based on optimized ffmpeg functions...
hmm, it sounds a little like you are talking about libavcodec/dct-test.c
while iam talking about tests/dsptest.c whos existence i honestly
wasnt aware of until today :)
Same here, I kept confusing it with the one in libavcodec.
Michael, OK to remove the file then?

Diego
Michael Niedermayer
2007-05-24 21:51:19 UTC
Permalink
Hi
Post by Diego Biurrun
Post by Diego Biurrun
Post by Michael Niedermayer
Post by Arpi
Post by Michael Niedermayer
Post by Diego Biurrun
Post by Michael Niedermayer
i guess i wouldnt be opposed to svn remove dsptest.c ...
Did it outlive its usefulness? Then it should go ...
well look at svn log dsptest.c, the last non cosmetic change was r613
i didnt even know that this file existed :)
it uses its own benchmarking code (which is x86 gcc specific, this wont
even compile anywhere else)
it only supports a very tiny subset of the dsp functions
so what IS it good for?
it served as a "good" documentation on the dct functions and permutations
relations and usage for me, when i was experimenting with some new codec
ideas based on optimized ffmpeg functions...
hmm, it sounds a little like you are talking about libavcodec/dct-test.c
while iam talking about tests/dsptest.c whos existence i honestly
wasnt aware of until today :)
Same here, I kept confusing it with the one in libavcodec.
Michael, OK to remove the file then?
yes

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

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato
Ronald S. Bultje
2007-05-22 04:59:36 UTC
Permalink
Hi,
Post by Michael Niedermayer
Post by Ronald S. Bultje
dsptest in tests/ and cputest in lavc/i386/ can't be compiled, since
they use internaly API (dsptest is about ten pages of warnings, so
cputest.c:83: error: 'MM_MMX' undeclared (first use in this function)
cputest.c:83: error: (Each undeclared identifier is reported only once
cputest.c:83: error: for each function it appears in.)
cputest.c:85: error: 'MM_MMXEXT' undeclared (first use in this function)
cputest.c:85: error: 'MM_SSE' undeclared (first use in this function)
cputest.c:87: error: 'MM_SSE2' undeclared (first use in this function)
cputest.c:89: error: 'MM_SSE3' undeclared (first use in this function)
cputest.c:91: error: 'MM_SSSE3' undeclared (first use in this function)
cputest.c:99: error: 'MM_3DNOW' undeclared (first use in this function)
cputest.c:101: error: 'MM_3DNOWEXT' undeclared (first use in this
function)
this should be useing FF_MM_MMX and similar
There's a small problem there, avcodec.h defines those if HAVE_MMX is
defined, which is in config.h. config.h is only included if
HAVE_AV_CONFIG_H is defined (in libavutil/common.h). This is actually a
larger problem, since an installed ffmpeg would lose the config.h and
thus apps would need to manually check whether their ffmpeg lib is
compiled with MMX to be able to use any of this API. It (FF_MM_*) should
either be moved out of avcodec.h and re-privatized, or parts of config.h
should be moved to an installed ffconfig.h or so.

Also, SS/SSSE3 are missing in the FF_MM_* list in avcodec.h, but that's
less of an issue (anyone want to apply the obvious patch?).

Ronald
Michael Niedermayer
2007-05-22 09:09:14 UTC
Permalink
Hi
Post by Ronald S. Bultje
Hi,
Post by Michael Niedermayer
Post by Ronald S. Bultje
dsptest in tests/ and cputest in lavc/i386/ can't be compiled, since
they use internaly API (dsptest is about ten pages of warnings, so
cputest.c:83: error: 'MM_MMX' undeclared (first use in this function)
cputest.c:83: error: (Each undeclared identifier is reported only once
cputest.c:83: error: for each function it appears in.)
cputest.c:85: error: 'MM_MMXEXT' undeclared (first use in this function)
cputest.c:85: error: 'MM_SSE' undeclared (first use in this function)
cputest.c:87: error: 'MM_SSE2' undeclared (first use in this function)
cputest.c:89: error: 'MM_SSE3' undeclared (first use in this function)
cputest.c:91: error: 'MM_SSSE3' undeclared (first use in this function)
cputest.c:99: error: 'MM_3DNOW' undeclared (first use in this function)
cputest.c:101: error: 'MM_3DNOWEXT' undeclared (first use in this
function)
this should be useing FF_MM_MMX and similar
There's a small problem there, avcodec.h defines those if HAVE_MMX is
this is wrong they should always be defined, they are needed to set
AVCodecContext.dsp_mask

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

No snowflake in an avalanche ever feels responsible. -- Voltaire
Ronald S. Bultje
2007-06-07 12:57:46 UTC
Permalink
Hi,
Post by Michael Niedermayer
Hi
Post by Ronald S. Bultje
Hi,
Post by Michael Niedermayer
Post by Ronald S. Bultje
dsptest in tests/ and cputest in lavc/i386/ can't be compiled, since
they use internaly API (dsptest is about ten pages of warnings, so
cputest.c:83: error: 'MM_MMX' undeclared (first use in this function)
cputest.c:83: error: (Each undeclared identifier is reported only once
cputest.c:83: error: for each function it appears in.)
cputest.c:85: error: 'MM_MMXEXT' undeclared (first use in this function)
cputest.c:85: error: 'MM_SSE' undeclared (first use in this function)
cputest.c:87: error: 'MM_SSE2' undeclared (first use in this function)
cputest.c:89: error: 'MM_SSE3' undeclared (first use in this function)
cputest.c:91: error: 'MM_SSSE3' undeclared (first use in this function)
cputest.c:99: error: 'MM_3DNOW' undeclared (first use in this function)
cputest.c:101: error: 'MM_3DNOWEXT' undeclared (first use in this
function)
this should be useing FF_MM_MMX and similar
There's a small problem there, avcodec.h defines those if HAVE_MMX is
this is wrong they should always be defined, they are needed to set
AVCodecContext.dsp_mask
Patch attached to fix it. Now, cputest compiles w/o HAVE_AV_CONFIG_H
fine.

Ronald
Index: avcodec.h
===================================================================
--- avcodec.h (revision 9221)
+++ avcodec.h (working copy)
@@ -1305,17 +1305,15 @@
unsigned dsp_mask;
#define FF_MM_FORCE 0x80000000 /* Force usage of selected flags (OR) */
/* lower 16 bits - CPU features */
-#ifdef HAVE_MMX
#define FF_MM_MMX 0x0001 /* standard MMX */
#define FF_MM_3DNOW 0x0004 /* AMD 3DNOW */
#define FF_MM_MMXEXT 0x0002 /* SSE integer functions or AMD MMX ext */
#define FF_MM_SSE 0x0008 /* SSE functions */
#define FF_MM_SSE2 0x0010 /* PIV SSE2 functions */
#define FF_MM_3DNOWEXT 0x0020 /* AMD 3DNowExt */
-#endif /* HAVE_MMX */
-#ifdef HAVE_IWMMXT
+#define FF_MM_SSE3 0x0040 /* Prescott SSE3 functions */
+#define FF_MM_SSSE3 0x0080 /* Conroe SSSE3 functions */
#define FF_MM_IWMMXT 0x0100 /* XScale IWMMXT */
-#endif /* HAVE_IWMMXT */

/**
* bits per sample/pixel from the demuxer (needed for huffyuv).
Index: i386/cputest.c
===================================================================
--- i386/cputest.c (revision 9221)
+++ i386/cputest.c (working copy)
@@ -80,15 +80,15 @@
if(max_std_level >= 1){
cpuid(1, eax, ebx, ecx, std_caps);
if (std_caps & (1<<23))
- rval |= MM_MMX;
+ rval |= FF_MM_MMX;
if (std_caps & (1<<25))
- rval |= MM_MMXEXT | MM_SSE;
+ rval |= FF_MM_MMXEXT | FF_MM_SSE;
if (std_caps & (1<<26))
- rval |= MM_SSE2;
+ rval |= FF_MM_SSE2;
if (ecx & 1)
- rval |= MM_SSE3;
+ rval |= FF_MM_SSE3;
if (ecx & 0x00000200 )
- rval |= MM_SSSE3;
+ rval |= FF_MM_SSSE3;
}

cpuid(0x80000000, max_ext_level, ebx, ecx, edx);
@@ -96,25 +96,25 @@
if(max_ext_level >= 0x80000001){
cpuid(0x80000001, eax, ebx, ecx, ext_caps);
if (ext_caps & (1<<31))
- rval |= MM_3DNOW;
+ rval |= FF_MM_3DNOW;
if (ext_caps & (1<<30))
- rval |= MM_3DNOWEXT;
+ rval |= FF_MM_3DNOWEXT;
if (ext_caps & (1<<23))
- rval |= MM_MMX;
+ rval |= FF_MM_MMX;
if (ext_caps & (1<<22))
- rval |= MM_MMXEXT;
+ rval |= FF_MM_MMXEXT;
}

#if 0
av_log(NULL, AV_LOG_DEBUG, "%s%s%s%s%s%s%s%s\n",
- (rval&MM_MMX) ? "MMX ":"",
- (rval&MM_MMXEXT) ? "MMX2 ":"",
- (rval&MM_SSE) ? "SSE ":"",
- (rval&MM_SSE2) ? "SSE2 ":"",
- (rval&MM_SSE3) ? "SSE3 ":"",
- (rval&MM_SSSE3) ? "SSSE3 ":"",
- (rval&MM_3DNOW) ? "3DNow ":"",
- (rval&MM_3DNOWEXT) ? "3DNowExt ":"");
+ (rval&FF_MM_MMX) ? "MMX ":"",
+ (rval&FF_MM_MMXEXT) ? "MMX2 ":"",
+ (rval&FF_MM_SSE) ? "SSE ":"",
+ (rval&FF_MM_SSE2) ? "SSE2 ":"",
+ (rval&FF_MM_SSE3) ? "SSE3 ":"",
+ (rval&FF_MM_SSSE3) ? "SSSE3 ":"",
+ (rval&FF_MM_3DNOW) ? "3DNow ":"",
+ (rval&FF_MM_3DNOWEXT) ? "3DNowExt ":"");
#endif
return rval;
}
Michael Niedermayer
2007-06-07 13:56:26 UTC
Permalink
Hi
Post by Ronald S. Bultje
Hi,
Post by Michael Niedermayer
Hi
Post by Ronald S. Bultje
Hi,
Post by Michael Niedermayer
Post by Ronald S. Bultje
dsptest in tests/ and cputest in lavc/i386/ can't be compiled, since
they use internaly API (dsptest is about ten pages of warnings, so
cputest.c:83: error: 'MM_MMX' undeclared (first use in this function)
cputest.c:83: error: (Each undeclared identifier is reported only once
cputest.c:83: error: for each function it appears in.)
cputest.c:85: error: 'MM_MMXEXT' undeclared (first use in this function)
cputest.c:85: error: 'MM_SSE' undeclared (first use in this function)
cputest.c:87: error: 'MM_SSE2' undeclared (first use in this function)
cputest.c:89: error: 'MM_SSE3' undeclared (first use in this function)
cputest.c:91: error: 'MM_SSSE3' undeclared (first use in this function)
cputest.c:99: error: 'MM_3DNOW' undeclared (first use in this function)
cputest.c:101: error: 'MM_3DNOWEXT' undeclared (first use in this
function)
this should be useing FF_MM_MMX and similar
There's a small problem there, avcodec.h defines those if HAVE_MMX is
this is wrong they should always be defined, they are needed to set
AVCodecContext.dsp_mask
Patch attached to fix it. Now, cputest compiles w/o HAVE_AV_CONFIG_H
fine.
looks ok

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

When the tyrant has disposed of foreign enemies by conquest or treaty, and
there is nothing more to fear from them, then he is always stirring up
some war or other, in order that the people may require a leader. -- Plato
Diego Biurrun
2007-06-07 17:22:57 UTC
Permalink
Post by Michael Niedermayer
Post by Ronald S. Bultje
Post by Michael Niedermayer
Post by Ronald S. Bultje
Post by Michael Niedermayer
Post by Ronald S. Bultje
dsptest in tests/ and cputest in lavc/i386/ can't be compiled, since
they use internaly API (dsptest is about ten pages of warnings, so
cputest.c:83: error: 'MM_MMX' undeclared (first use in this function)
cputest.c:83: error: (Each undeclared identifier is reported only once
cputest.c:83: error: for each function it appears in.)
cputest.c:85: error: 'MM_MMXEXT' undeclared (first use in this function)
cputest.c:85: error: 'MM_SSE' undeclared (first use in this function)
cputest.c:87: error: 'MM_SSE2' undeclared (first use in this function)
cputest.c:89: error: 'MM_SSE3' undeclared (first use in this function)
cputest.c:91: error: 'MM_SSSE3' undeclared (first use in this function)
cputest.c:99: error: 'MM_3DNOW' undeclared (first use in this function)
cputest.c:101: error: 'MM_3DNOWEXT' undeclared (first use in this
function)
this should be useing FF_MM_MMX and similar
There's a small problem there, avcodec.h defines those if HAVE_MMX is
this is wrong they should always be defined, they are needed to set
AVCodecContext.dsp_mask
Patch attached to fix it. Now, cputest compiles w/o HAVE_AV_CONFIG_H
fine.
looks ok
Applied in several steps.

Diego
Ronald S. Bultje
2007-06-07 13:01:44 UTC
Permalink
Hi,
Post by Michael Niedermayer
Post by Ronald S. Bultje
Post by Michael Niedermayer
split it :)
Ok, how?
so that no 2 unrelated changes are in 1 patch, emms->emms_c and
HAVE_GPL for example are unrelated
Attached patch is the remaining emms() function in lavf/grab.c. Someone
already moved the test ones over to emms_c().

Ronald
Index: grab.c
===================================================================
--- grab.c (revision 9221)
+++ grab.c (working copy)
@@ -839,9 +839,7 @@
DEINT_LINE_LUM(12)
}
}
-#ifdef HAVE_MMX
- emms();
-#endif
+ emms_c();
return s->frame_size;
}
Diego Biurrun
2007-06-07 13:24:37 UTC
Permalink
Post by Ronald S. Bultje
Post by Michael Niedermayer
Post by Ronald S. Bultje
Post by Michael Niedermayer
split it :)
Ok, how?
so that no 2 unrelated changes are in 1 patch, emms->emms_c and
HAVE_GPL for example are unrelated
Attached patch is the remaining emms() function in lavf/grab.c. Someone
already moved the test ones over to emms_c().
Applied.

Diego
Diego Biurrun
2007-06-07 14:14:17 UTC
Permalink
Post by Ronald S. Bultje
Post by Michael Niedermayer
Post by Ronald S. Bultje
Post by Michael Niedermayer
split it :)
Ok, how?
so that no 2 unrelated changes are in 1 patch, emms->emms_c and
HAVE_GPL for example are unrelated
Attached patch is the remaining emms() function in lavf/grab.c. Someone
already moved the test ones over to emms_c().
--- grab.c (revision 9221)
+++ grab.c (working copy)
@@ -839,9 +839,7 @@
}
-#ifdef HAVE_MMX
- emms();
-#endif
+ emms_c();
This was missing a dsputil.h #include, emms_c is a macro. I'm sharing
the Cola with you. Fixed.

Diego
Ronald S. Bultje
2007-06-07 13:05:03 UTC
Permalink
Hi,
Post by Ronald S. Bultje
dsputil.h:688: warning: implicit declaration of function 'ST16'
dsputil.h:688: warning: implicit declaration of function 'LD16'
dsputil.h:699: warning: implicit declaration of function 'ST32'
dsputil.h:699: warning: implicit declaration of function 'LD32'
dct-test.c:333: warning: implicit declaration of function 'sqrt'
dct-test.c:333: warning: incompatible implicit declaration of built-in
function 'sqrt'
dct-test.c:334: warning: implicit declaration of function 'cos'
dct-test.c:334: warning: incompatible implicit declaration of built-in
function 'cos'
dct-test.c:334: error: 'M_PI' undeclared (first use in this function)
dct-test.c:334: error: (Each undeclared identifier is reported only once
dct-test.c:334: error: for each function it appears in.)
dct-test.c:342: warning: incompatible implicit declaration of built-in
function 'sqrt'
dct-test.c:343: warning: incompatible implicit declaration of built-in
function 'cos'
dct-test.c:350: warning: incompatible implicit declaration of built-in
function 'sqrt'
dct-test.c:393: warning: implicit declaration of function 'rint'
dct-test.c:393: warning: incompatible implicit declaration of built-in
function 'rint'
I can work around this by adding an include for math.h.
And attached is the last patch to fix dct-test. It needs math.h for M_PI
and definitions of functions such as sqrt() (normally through
HAVE_AV_CONFIG_H, but we're trying without now). Then, it needs
CONFIG_GPL/MMX awareness for those of us not using GPL code. Lastly,
since we no longer use HAVE_AV_CONFIG_H, the #undef printf can go away.

Ronald
Index: dct-test.c
===================================================================
--- dct-test.c (revision 9221)
+++ dct-test.c (working copy)
@@ -30,6 +30,7 @@
#include <string.h>
#include <sys/time.h>
#include <unistd.h>
+#include <math.h>

#include "dsputil.h"

@@ -40,8 +41,6 @@
#define MAX(a, b) (((a) > (b)) ? (a) : (b))
#endif

-#undef printf
-
void *fast_memcpy(void *a, const void *b, size_t c){return memcpy(a,b,c);};

/* reference fdct/idct */
@@ -91,16 +90,20 @@
DCT_ERROR("SIMPLE-C", 1, simple_idct, idct, NO_PERM),

#ifdef ARCH_X86
+ DCT_ERROR("FAAN", 0, ff_faandct, fdct, FAAN_SCALE),
+#ifdef HAVE_MMX
DCT_ERROR("MMX", 0, ff_fdct_mmx, fdct, NO_PERM),
DCT_ERROR("MMX2", 0, ff_fdct_mmx2, fdct, NO_PERM),
- DCT_ERROR("FAAN", 0, ff_faandct, fdct, FAAN_SCALE),

DCT_ERROR("LIBMPEG2-MMX", 1, ff_mmx_idct, idct, MMX_PERM),
DCT_ERROR("LIBMPEG2-MMXEXT", 1, ff_mmxext_idct, idct, MMX_PERM),
DCT_ERROR("SIMPLE-MMX", 1, ff_simple_idct_mmx, idct, MMX_SIMPLE_PERM),
+#ifdef CONFIG_GPL
DCT_ERROR("XVID-MMX", 1, ff_idct_xvid_mmx, idct, NO_PERM),
DCT_ERROR("XVID-MMX2", 1, ff_idct_xvid_mmx2, idct, NO_PERM),
#endif
+#endif
+#endif

#ifdef HAVE_ALTIVEC
DCT_ERROR("altivecfdct", 0, fdct_altivec, fdct, NO_PERM),
Michael Niedermayer
2007-06-07 14:01:20 UTC
Permalink
Hi
Post by Ronald S. Bultje
Hi,
Post by Ronald S. Bultje
dsputil.h:688: warning: implicit declaration of function 'ST16'
dsputil.h:688: warning: implicit declaration of function 'LD16'
dsputil.h:699: warning: implicit declaration of function 'ST32'
dsputil.h:699: warning: implicit declaration of function 'LD32'
dct-test.c:333: warning: implicit declaration of function 'sqrt'
dct-test.c:333: warning: incompatible implicit declaration of built-in
function 'sqrt'
dct-test.c:334: warning: implicit declaration of function 'cos'
dct-test.c:334: warning: incompatible implicit declaration of built-in
function 'cos'
dct-test.c:334: error: 'M_PI' undeclared (first use in this function)
dct-test.c:334: error: (Each undeclared identifier is reported only once
dct-test.c:334: error: for each function it appears in.)
dct-test.c:342: warning: incompatible implicit declaration of built-in
function 'sqrt'
dct-test.c:343: warning: incompatible implicit declaration of built-in
function 'cos'
dct-test.c:350: warning: incompatible implicit declaration of built-in
function 'sqrt'
dct-test.c:393: warning: implicit declaration of function 'rint'
dct-test.c:393: warning: incompatible implicit declaration of built-in
function 'rint'
I can work around this by adding an include for math.h.
And attached is the last patch to fix dct-test. It needs math.h for M_PI
and definitions of functions such as sqrt() (normally through
HAVE_AV_CONFIG_H, but we're trying without now). Then, it needs
CONFIG_GPL/MMX awareness for those of us not using GPL code. Lastly,
since we no longer use HAVE_AV_CONFIG_H, the #undef printf can go away.
shouldnt these be in seperate patches ...

[...]
Post by Ronald S. Bultje
#ifdef ARCH_X86
+ DCT_ERROR("FAAN", 0, ff_faandct, fdct, FAAN_SCALE),
+#ifdef HAVE_MMX
DCT_ERROR("MMX", 0, ff_fdct_mmx, fdct, NO_PERM),
DCT_ERROR("MMX2", 0, ff_fdct_mmx2, fdct, NO_PERM),
- DCT_ERROR("FAAN", 0, ff_faandct, fdct, FAAN_SCALE),
FAAN is not x86 specific

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

I have often repented speaking, but never of holding my tongue.
-- Xenocrates
Diego Biurrun
2007-06-07 16:07:22 UTC
Permalink
Post by Ronald S. Bultje
And attached is the last patch to fix dct-test. It needs math.h for M_PI
and definitions of functions such as sqrt() (normally through
HAVE_AV_CONFIG_H, but we're trying without now). Then, it needs
CONFIG_GPL/MMX awareness for those of us not using GPL code. Lastly,
since we no longer use HAVE_AV_CONFIG_H, the #undef printf can go away.
I don't see where we are trying without now ..
Post by Ronald S. Bultje
--- dct-test.c (revision 9221)
+++ dct-test.c (working copy)
@@ -30,6 +30,7 @@
#include <string.h>
#include <sys/time.h>
#include <unistd.h>
+#include <math.h>
#include "dsputil.h"
@@ -40,8 +41,6 @@
#define MAX(a, b) (((a) > (b)) ? (a) : (b))
#endif
-#undef printf
This is not for us, we compile with HAVE_AV_CONFIG_H.
Post by Ronald S. Bultje
@@ -91,16 +90,20 @@
DCT_ERROR("SIMPLE-C", 1, simple_idct, idct, NO_PERM),
#ifdef ARCH_X86
+ DCT_ERROR("FAAN", 0, ff_faandct, fdct, FAAN_SCALE),
+#ifdef HAVE_MMX
DCT_ERROR("MMX", 0, ff_fdct_mmx, fdct, NO_PERM),
DCT_ERROR("MMX2", 0, ff_fdct_mmx2, fdct, NO_PERM),
- DCT_ERROR("FAAN", 0, ff_faandct, fdct, FAAN_SCALE),
The MMX2 test should be within HAVE_MMX2, not HAVE_MMX. Michael already
mentioned that FAAN is not x86-specific.
Post by Ronald S. Bultje
DCT_ERROR("LIBMPEG2-MMX", 1, ff_mmx_idct, idct, MMX_PERM),
DCT_ERROR("LIBMPEG2-MMXEXT", 1, ff_mmxext_idct, idct, MMX_PERM),
DCT_ERROR("SIMPLE-MMX", 1, ff_simple_idct_mmx, idct, MMX_SIMPLE_PERM),
+#ifdef CONFIG_GPL
DCT_ERROR("XVID-MMX", 1, ff_idct_xvid_mmx, idct, NO_PERM),
DCT_ERROR("XVID-MMX2", 1, ff_idct_xvid_mmx2, idct, NO_PERM),
#endif
+#endif
This is wrong, ff_mmx_idct and ff_mmxext_idct are compiled conditional
to CONFIG_GPL, ff_idct_xvid_mmx and ff_idct_xvid_mmx2 are not.

Everything fixed.

Diego
Ronald S. Bultje
2007-06-07 13:12:55 UTC
Permalink
Hi again,
Post by Ronald S. Bultje
dsputil.h:688: warning: implicit declaration of function 'ST16'
dsputil.h:688: warning: implicit declaration of function 'LD16'
dsputil.h:699: warning: implicit declaration of function 'ST32'
dsputil.h:699: warning: implicit declaration of function 'LD32'
fft-test.c:129: warning: implicit declaration of function 'random'
fft-test.c:161: warning: implicit declaration of function 'exit'
fft-test.c:161: warning: incompatible implicit declaration of built-in
function 'exit'
fft-test.c:198: warning: implicit declaration of function 'atoi'
fft-test.c:249: warning: implicit declaration of function 'memcpy'
fft-test.c:249: warning: incompatible implicit declaration of built-in
function 'memcpy'
fft-test.c:276: warning: incompatible implicit declaration of built-in
function 'memcpy'
I can work around this by adding includes for stdlib.h and string.h to
fft-test.c.
See attached. I also removed the undef exit because it is no longer
needed if we don't use HAVE_AV_CONFIG_H.

Ronald
Index: libavcodec/fft-test.c
===================================================================
--- libavcodec/fft-test.c (revision 9221)
+++ libavcodec/fft-test.c (working copy)
@@ -27,9 +27,9 @@
#include <math.h>
#include <unistd.h>
#include <sys/time.h>
+#include <stdlib.h>
+#include <string.h>

-#undef exit
-
int mm_flags;

/* reference fft */
Michael Niedermayer
2007-06-07 14:03:17 UTC
Permalink
Hi
Post by Ronald S. Bultje
Hi again,
Post by Ronald S. Bultje
dsputil.h:688: warning: implicit declaration of function 'ST16'
dsputil.h:688: warning: implicit declaration of function 'LD16'
dsputil.h:699: warning: implicit declaration of function 'ST32'
dsputil.h:699: warning: implicit declaration of function 'LD32'
fft-test.c:129: warning: implicit declaration of function 'random'
fft-test.c:161: warning: implicit declaration of function 'exit'
fft-test.c:161: warning: incompatible implicit declaration of built-in
function 'exit'
fft-test.c:198: warning: implicit declaration of function 'atoi'
fft-test.c:249: warning: implicit declaration of function 'memcpy'
fft-test.c:249: warning: incompatible implicit declaration of built-in
function 'memcpy'
fft-test.c:276: warning: incompatible implicit declaration of built-in
function 'memcpy'
I can work around this by adding includes for stdlib.h and string.h to
fft-test.c.
See attached. I also removed the undef exit because it is no longer
needed if we don't use HAVE_AV_CONFIG_H.
this is ok if it doesnt break compilation (=we dont use HAVE_AV_CONFIG_H for
it)

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

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus
Diego Biurrun
2007-06-07 20:45:04 UTC
Permalink
Post by Ronald S. Bultje
Post by Ronald S. Bultje
dsputil.h:688: warning: implicit declaration of function 'ST16'
dsputil.h:688: warning: implicit declaration of function 'LD16'
dsputil.h:699: warning: implicit declaration of function 'ST32'
dsputil.h:699: warning: implicit declaration of function 'LD32'
fft-test.c:129: warning: implicit declaration of function 'random'
fft-test.c:161: warning: implicit declaration of function 'exit'
fft-test.c:161: warning: incompatible implicit declaration of built-in
function 'exit'
fft-test.c:198: warning: implicit declaration of function 'atoi'
fft-test.c:249: warning: implicit declaration of function 'memcpy'
fft-test.c:249: warning: incompatible implicit declaration of built-in
function 'memcpy'
fft-test.c:276: warning: incompatible implicit declaration of built-in
function 'memcpy'
I can work around this by adding includes for stdlib.h and string.h to
fft-test.c.
See attached. I also removed the undef exit because it is no longer
needed if we don't use HAVE_AV_CONFIG_H.
--- libavcodec/fft-test.c (revision 9221)
+++ libavcodec/fft-test.c (working copy)
@@ -27,9 +27,9 @@
#include <math.h>
#include <unistd.h>
#include <sys/time.h>
+#include <stdlib.h>
+#include <string.h>
-#undef exit
-
int mm_flags;
This is wrong, we compile with HAVE_AV_CONFIG_H and need the #undef.

Diego
Ronald S. Bultje
2007-06-07 23:29:42 UTC
Permalink
Hi,
Post by Diego Biurrun
Post by Ronald S. Bultje
--- libavcodec/fft-test.c (revision 9221)
+++ libavcodec/fft-test.c (working copy)
@@ -27,9 +27,9 @@
#include <math.h>
#include <unistd.h>
#include <sys/time.h>
+#include <stdlib.h>
+#include <string.h>
-#undef exit
-
int mm_flags;
This is wrong, we compile with HAVE_AV_CONFIG_H and need the #undef.
Can you commit the includes then? Same for the math.h include in
dct-test.c. They would at some point, for example tonight, allow you to
remove HAVE_AV_CONFIG_H for those apps (and then after that, you could
still remove the undefs at some later point).

Ronald
Diego Biurrun
2007-06-09 17:53:38 UTC
Permalink
Post by Ronald S. Bultje
Post by Diego Biurrun
Post by Ronald S. Bultje
--- libavcodec/fft-test.c (revision 9221)
+++ libavcodec/fft-test.c (working copy)
@@ -27,9 +27,9 @@
#include <math.h>
#include <unistd.h>
#include <sys/time.h>
+#include <stdlib.h>
+#include <string.h>
-#undef exit
-
int mm_flags;
This is wrong, we compile with HAVE_AV_CONFIG_H and need the #undef.
Can you commit the includes then? Same for the math.h include in
dct-test.c. They would at some point, for example tonight, allow you to
remove HAVE_AV_CONFIG_H for those apps (and then after that, you could
still remove the undefs at some later point).
Yes, I can and I have just done so.

I would appreciate if you could send the remaining changes for
motion-test.c now.

Diego
Ronald S. Bultje
2007-06-09 18:23:33 UTC
Permalink
Hi,
Post by Diego Biurrun
I would appreciate if you could send the remaining changes for
motion-test.c now.
Oops, accidently forgot them, please find it attached. Works for me,
although the time calculated to run the test always gives nan here, not sure
why. Maybe my cpu is extremely fast? :-).

Ronald
Diego Biurrun
2007-06-09 18:33:01 UTC
Permalink
Post by Ronald S. Bultje
Post by Diego Biurrun
I would appreciate if you could send the remaining changes for
motion-test.c now.
Oops, accidently forgot them, please find it attached. Works for me,
although the time calculated to run the test always gives nan here, not sure
why. Maybe my cpu is extremely fast? :-).
--- motion-test.c (revision 9254)
+++ motion-test.c (working copy)
@@ -29,28 +29,11 @@
#include <sys/time.h>
#include <unistd.h>
+#include "avcodec.h"
#include "dsputil.h"
dsputil.h #includes avcodec.h, so this is unnecessary.
Post by Ronald S. Bultje
#include "i386/mmx.h"
-#undef exit
-#undef printf
You'll likely keep insisting, but these are not for us..
Post by Ronald S. Bultje
@@ -137,13 +120,16 @@
int main(int argc, char **argv)
{
- int c;
+ AVCodecContext *ctx;
+ int n;
+ DSPContext c, mmx;
+ int flags[2] = { FF_MM_MMX, FF_MM_MMXEXT };
for(;;) {
- c = getopt(argc, argv, "h");
- if (c == -1)
+ n = getopt(argc, argv, "h");
+ if (n == -1)
break;
- switch(c) {
+ switch(n) {
I think this can be called cosmetics. Why not use another variable name
for the DSPContext? One character variable names are not the best idea
in the first place ...
Post by Ronald S. Bultje
@@ -152,9 +138,24 @@
+ test_motion("mmx", mmx.pix_abs[x][0], c.pix_abs[x][0]);
+ test_motion("mmx_x2", mmx.pix_abs[x][1], c.pix_abs[x][1]);
+ test_motion("mmx_y2", mmx.pix_abs[x][2], c.pix_abs[x][2]);
+ test_motion("mmx_xy2", mmx.pix_abs[x][3], c.pix_abs[x][3]);
This could be nicely aligned...

Diego
Ronald S. Bultje
2007-06-09 18:40:35 UTC
Permalink
Hi Diego,
Post by Diego Biurrun
--- motion-test.c (revision 9254)
+++ motion-test.c (working copy)
@@ -29,28 +29,11 @@
#include <sys/time.h>
#include <unistd.h>
+#include "avcodec.h"
#include "dsputil.h"
dsputil.h #includes avcodec.h, so this is unnecessary.
Interesting. So, without the avcodec.h include, it says it can't find the
FF_MM_* symbols. Any idea why?
Post by Diego Biurrun
#include "i386/mmx.h"
-#undef exit
-#undef printf
You'll likely keep insisting, but these are not for us..
Will remove.
Post by Diego Biurrun
@@ -137,13 +120,16 @@
int main(int argc, char **argv)
{
- int c;
+ AVCodecContext *ctx;
+ int n;
+ DSPContext c, mmx;
+ int flags[2] = { FF_MM_MMX, FF_MM_MMXEXT };
for(;;) {
- c = getopt(argc, argv, "h");
- if (c == -1)
+ n = getopt(argc, argv, "h");
+ if (n == -1)
break;
- switch(c) {
+ switch(n) {
I think this can be called cosmetics. Why not use another variable name
for the DSPContext? One character variable names are not the best idea
in the first place ...
also true. Will remove.
Post by Diego Biurrun
@@ -152,9 +138,24 @@
+ test_motion("mmx", mmx.pix_abs[x][0], c.pix_abs[x][0]);
+ test_motion("mmx_x2", mmx.pix_abs[x][1], c.pix_abs[x][1]);
+ test_motion("mmx_y2", mmx.pix_abs[x][2], c.pix_abs[x][2]);
+ test_motion("mmx_xy2", mmx.pix_abs[x][3], c.pix_abs[x][3]);
This could be nicely aligned...
See attached again.

Ronald
Ronald S. Bultje
2007-06-09 18:41:22 UTC
Permalink
Hi,
Post by Diego Biurrun
dsputil.h #includes avcodec.h, so this is unnecessary.
Interesting. So, without the avcodec.h include, it says it can't find the
FF_MM_* symbols. Any idea why?
Apparently it doesn't, must've been a typo of some sort. Sorry for the
noise.

Ronald
Diego Biurrun
2007-06-09 19:01:47 UTC
Permalink
Post by Ronald S. Bultje
See attached again.
I'll apply it in a moment, thanks. Can anybody suggest a better commit
log message than "compilation fix"? I'm not particularly imaginative
right now...

Diego
Diego Biurrun
2007-06-10 13:54:54 UTC
Permalink
Post by Diego Biurrun
Post by Ronald S. Bultje
See attached again.
I'll apply it in a moment, thanks. Can anybody suggest a better commit
log message than "compilation fix"? I'm not particularly imaginative
right now...
Applied.

Ronald, was that the last part of your patch set or is there some part
still pending and/or do you have some more?

Diego
Ronald S. Bultje
2007-06-10 14:32:17 UTC
Permalink
Hi Diego,
Post by Diego Biurrun
Post by Diego Biurrun
Post by Ronald S. Bultje
See attached again.
I'll apply it in a moment, thanks. Can anybody suggest a better commit
log message than "compilation fix"? I'm not particularly imaginative
right now...
Applied.
Ronald, was that the last part of your patch set or is there some part
still pending and/or do you have some more?
It's the last of this series, thanks for getting everything in. Maybe I
should submit the autotools (autogen.sh, configure.ac, */Makefile.am) again
if you wish, it's the only remaining part... :-).

Anyway, I'm working on other new features but they're not finished yet,
they'll come in soon.

Ronald

Diego Biurrun
2007-05-21 22:41:39 UTC
Permalink
Post by Ronald S. Bultje
Post by Michael Niedermayer
Post by Ronald S. Bultje
--- ffmpeg.orig/libavcodec/fft-test.c 2007-03-22 01:00:48.000000000 -0400
+++ ffmpeg/libavcodec/fft-test.c 2007-03-22 01:20:53.000000000 -0400
@@ -28,6 +28,9 @@
#include <unistd.h>
#include <sys/time.h>
+#undef fprintf
+#undef printf
+
int mm_flags;
/* reference fft */
there is no *printf in fft-test.c
and ive not checked that the other undefs are needed but that must be checked
before such changes can be accpeted also teh question remains why
HAVE_AV_CONFIG_H is defined at all for these files
dsputil.h:688: warning: implicit declaration of function 'ST16'
dsputil.h:688: warning: implicit declaration of function 'LD16'
dsputil.h:699: warning: implicit declaration of function 'ST32'
dsputil.h:699: warning: implicit declaration of function 'LD32'
dct-test.c:333: warning: implicit declaration of function 'sqrt'
dct-test.c:333: warning: incompatible implicit declaration of built-in
function 'sqrt'
dct-test.c:334: warning: implicit declaration of function 'cos'
dct-test.c:334: warning: incompatible implicit declaration of built-in
function 'cos'
dct-test.c:334: error: 'M_PI' undeclared (first use in this function)
dct-test.c:334: error: (Each undeclared identifier is reported only once
dct-test.c:334: error: for each function it appears in.)
dct-test.c:342: warning: incompatible implicit declaration of built-in
function 'sqrt'
dct-test.c:343: warning: incompatible implicit declaration of built-in
function 'cos'
dct-test.c:350: warning: incompatible implicit declaration of built-in
function 'sqrt'
dct-test.c:393: warning: implicit declaration of function 'rint'
dct-test.c:393: warning: incompatible implicit declaration of built-in
function 'rint'
I can work around this by adding an include for math.h.
What environment are you compiling on? It works fine here on x86,
Debian stable.
Post by Ronald S. Bultje
dsputil.h:688: warning: implicit declaration of function 'ST16'
dsputil.h:688: warning: implicit declaration of function 'LD16'
dsputil.h:699: warning: implicit declaration of function 'ST32'
dsputil.h:699: warning: implicit declaration of function 'LD32'
fft-test.c:129: warning: implicit declaration of function 'random'
fft-test.c:161: warning: implicit declaration of function 'exit'
fft-test.c:161: warning: incompatible implicit declaration of built-in
function 'exit'
fft-test.c:198: warning: implicit declaration of function 'atoi'
fft-test.c:249: warning: implicit declaration of function 'memcpy'
fft-test.c:249: warning: incompatible implicit declaration of built-in
function 'memcpy'
fft-test.c:276: warning: incompatible implicit declaration of built-in
function 'memcpy'
I can work around this by adding includes for stdlib.h and string.h to
fft-test.c.
Here is what I get:

gcc -Wl,--warn-common -Wl,--as-needed -Wl,-rpath-link,"/usr/src/ffmpeg"/libavcodec -Wl,-rpath-link,"/usr/src/ffmpeg"/libavformat -Wl,-rpath-link,"/usr/src/ffmpeg"/libavutil -o fft-test fft-test.o libavcodec.a mdct.o fft.o -L"/usr/src/ffmpeg"/libavutil -lavutil -lm -lz
mdct.o: In function `ff_mdct_calc':
/usr/src/ffmpeg/libavcodec/mdct.c:133: multiple definition of `ff_mdct_calc'
libavcodec.a(mdct.o):/usr/src/ffmpeg/libavcodec/mdct.c:133: first defined here
mdct.o: In function `ff_mdct_end':
/usr/src/ffmpeg/libavcodec/mdct.c:173: multiple definition of `ff_mdct_end'
libavcodec.a(mdct.o):/usr/src/ffmpeg/libavcodec/mdct.c:173: first defined here
mdct.o: In function `ff_mdct_init':
/usr/src/ffmpeg/libavcodec/mdct.c:32: multiple definition of `ff_mdct_init'
libavcodec.a(mdct.o):/usr/src/ffmpeg/libavcodec/mdct.c:32: first defined here
mdct.o: In function `ff_imdct_calc':
/usr/src/ffmpeg/libavcodec/mdct.c:81: multiple definition of `ff_imdct_calc'
libavcodec.a(mdct.o):/usr/src/ffmpeg/libavcodec/mdct.c:81: first defined here
fft.o: In function `ff_fft_calc_c':
/usr/src/ffmpeg/libavcodec/fft.c:162: multiple definition of `ff_fft_calc_c'
libavcodec.a(fft.o):/usr/src/ffmpeg/libavcodec/fft.c:162: first defined here
fft.o: In function `ff_fft_permute':
/usr/src/ffmpeg/libavcodec/fft.c:239: multiple definition of `ff_fft_permute'
libavcodec.a(fft.o):/usr/src/ffmpeg/libavcodec/fft.c:239: first defined here
fft.o: In function `ff_fft_end':
/usr/src/ffmpeg/libavcodec/fft.c:257: multiple definition of `ff_fft_end'
libavcodec.a(fft.o):/usr/src/ffmpeg/libavcodec/fft.c:257: first defined here
fft.o: In function `ff_fft_init':
/usr/src/ffmpeg/libavcodec/fft.c:34: multiple definition of `ff_fft_init'
libavcodec.a(fft.o):/usr/src/ffmpeg/libavcodec/fft.c:34: first defined here
collect2: ld returned 1 exit status
make: *** [fft-test] Error 1
Post by Ronald S. Bultje
--- ffmpeg.orig/libavcodec/dct-test.c 2007-03-22 01:00:46.000000000 -0400
+++ ffmpeg/libavcodec/dct-test.c 2007-05-21 09:28:31.000000000 -0400
@@ -39,8 +40,6 @@
#define MAX(a, b) (((a) > (b)) ? (a) : (b))
#endif
-#undef printf
Probably wrong.
Post by Ronald S. Bultje
--- ffmpeg.orig/libavcodec/motion_test.c 2007-03-22 01:00:50.000000000 -0400
+++ ffmpeg/libavcodec/motion_test.c 2007-05-21 09:06:35.000000000 -0400
@@ -31,24 +31,24 @@
-#undef printf
dito

Diego
Ronald S. Bultje
2007-05-22 04:48:51 UTC
Permalink
Hi Diego,
Post by Diego Biurrun
Post by Ronald S. Bultje
dsputil.h:688: warning: implicit declaration of function 'ST16'
dsputil.h:688: warning: implicit declaration of function 'LD16'
dsputil.h:699: warning: implicit declaration of function 'ST32'
dsputil.h:699: warning: implicit declaration of function 'LD32'
dct-test.c:333: warning: implicit declaration of function 'sqrt'
dct-test.c:333: warning: incompatible implicit declaration of built-in
function 'sqrt'
dct-test.c:334: warning: implicit declaration of function 'cos'
dct-test.c:334: warning: incompatible implicit declaration of built-in
function 'cos'
dct-test.c:334: error: 'M_PI' undeclared (first use in this function)
dct-test.c:334: error: (Each undeclared identifier is reported only once
dct-test.c:334: error: for each function it appears in.)
dct-test.c:342: warning: incompatible implicit declaration of built-in
function 'sqrt'
dct-test.c:343: warning: incompatible implicit declaration of built-in
function 'cos'
dct-test.c:350: warning: incompatible implicit declaration of built-in
function 'sqrt'
dct-test.c:393: warning: implicit declaration of function 'rint'
dct-test.c:393: warning: incompatible implicit declaration of built-in
function 'rint'
I can work around this by adding an include for math.h.
What environment are you compiling on? It works fine here on x86,
Debian stable.
This is OSX 10.4.9. I think Linux sort-of automatically includes most
math.h functions with other standard headers, so Linux doesn't really
need include math.h. I think it's proper to add the include for
portability reasons.
Post by Diego Biurrun
Post by Ronald S. Bultje
dsputil.h:688: warning: implicit declaration of function 'ST16'
dsputil.h:688: warning: implicit declaration of function 'LD16'
dsputil.h:699: warning: implicit declaration of function 'ST32'
dsputil.h:699: warning: implicit declaration of function 'LD32'
fft-test.c:129: warning: implicit declaration of function 'random'
fft-test.c:161: warning: implicit declaration of function 'exit'
fft-test.c:161: warning: incompatible implicit declaration of built-in
function 'exit'
fft-test.c:198: warning: implicit declaration of function 'atoi'
fft-test.c:249: warning: implicit declaration of function 'memcpy'
fft-test.c:249: warning: incompatible implicit declaration of built-in
function 'memcpy'
fft-test.c:276: warning: incompatible implicit declaration of built-in
function 'memcpy'
I can work around this by adding includes for stdlib.h and string.h to
fft-test.c.
gcc -Wl,--warn-common -Wl,--as-needed
-Wl,-rpath-link,"/usr/src/ffmpeg"/libavcodec
-Wl,-rpath-link,"/usr/src/ffmpeg"/libavformat
-Wl,-rpath-link,"/usr/src/ffmpeg"/libavutil -o fft-test fft-test.o
libavcodec.a mdct.o fft.o -L"/usr/src/ffmpeg"/libavutil -lavutil -lm -lz
^^^^^^^^^^^^ ^^^^^^ ^^^^^
Post by Diego Biurrun
/usr/src/ffmpeg/libavcodec/mdct.c:133: multiple definition of `ff_mdct_calc'
libavcodec.a(mdct.o):/usr/src/ffmpeg/libavcodec/mdct.c:133: first defined here
/usr/src/ffmpeg/libavcodec/mdct.c:173: multiple definition of `ff_mdct_end'
libavcodec.a(mdct.o):/usr/src/ffmpeg/libavcodec/mdct.c:173: first defined here
/usr/src/ffmpeg/libavcodec/mdct.c:32: multiple definition of `ff_mdct_init'
libavcodec.a(mdct.o):/usr/src/ffmpeg/libavcodec/mdct.c:32: first defined here
/usr/src/ffmpeg/libavcodec/mdct.c:81: multiple definition of `ff_imdct_calc'
libavcodec.a(mdct.o):/usr/src/ffmpeg/libavcodec/mdct.c:81: first defined here
/usr/src/ffmpeg/libavcodec/fft.c:162: multiple definition of `ff_fft_calc_c'
libavcodec.a(fft.o):/usr/src/ffmpeg/libavcodec/fft.c:162: first defined here
/usr/src/ffmpeg/libavcodec/fft.c:239: multiple definition of `ff_fft_permute'
libavcodec.a(fft.o):/usr/src/ffmpeg/libavcodec/fft.c:239: first defined here
/usr/src/ffmpeg/libavcodec/fft.c:257: multiple definition of `ff_fft_end'
libavcodec.a(fft.o):/usr/src/ffmpeg/libavcodec/fft.c:257: first defined here
/usr/src/ffmpeg/libavcodec/fft.c:34: multiple definition of `ff_fft_init'
libavcodec.a(fft.o):/usr/src/ffmpeg/libavcodec/fft.c:34: first defined here
collect2: ld returned 1 exit status
make: *** [fft-test] Error 1
You're including fft.o/mdct.o twice, once manually and once through
libavcodec.a. Oh, did I mention I don't use the ffmpeg build system?
Maybe I should include patches to that in my next patch so that it
actually builds for you guys, also. :-).
Post by Diego Biurrun
Post by Ronald S. Bultje
--- ffmpeg.orig/libavcodec/dct-test.c 2007-03-22 01:00:46.000000000 -0400
+++ ffmpeg/libavcodec/dct-test.c 2007-05-21 09:28:31.000000000 -0400
@@ -39,8 +40,6 @@
#define MAX(a, b) (((a) > (b)) ? (a) : (b))
#endif
-#undef printf
Probably wrong.
Post by Ronald S. Bultje
--- ffmpeg.orig/libavcodec/motion_test.c 2007-03-22 01:00:50.000000000 -0400
+++ ffmpeg/libavcodec/motion_test.c 2007-05-21 09:06:35.000000000 -0400
@@ -31,24 +31,24 @@
-#undef printf
dito
If I remove HAVE_AV_CONFIG_H, the #undef printf becomes unneeded, it's
solely there because we define HAVE_AV_CONFIG_H, which defines printf to
please_use_av_log or so. Michael suggested to get rid of
HAVE_AV_CONFIG_H, which makes the undef unneeded. I'll put this stuff in
several smaller patches which are better-documented and hopefully
prevent confusion, sorry for now...

Ronald
Diego Biurrun
2007-05-22 18:18:11 UTC
Permalink
Post by Ronald S. Bultje
Post by Diego Biurrun
Post by Ronald S. Bultje
dsputil.h:688: warning: implicit declaration of function 'ST16'
dsputil.h:688: warning: implicit declaration of function 'LD16'
dsputil.h:699: warning: implicit declaration of function 'ST32'
dsputil.h:699: warning: implicit declaration of function 'LD32'
dct-test.c:333: warning: implicit declaration of function 'sqrt'
dct-test.c:333: warning: incompatible implicit declaration of built-in
function 'sqrt'
dct-test.c:334: warning: implicit declaration of function 'cos'
dct-test.c:334: warning: incompatible implicit declaration of built-in
function 'cos'
dct-test.c:334: error: 'M_PI' undeclared (first use in this function)
dct-test.c:334: error: (Each undeclared identifier is reported only once
dct-test.c:334: error: for each function it appears in.)
dct-test.c:342: warning: incompatible implicit declaration of built-in
function 'sqrt'
dct-test.c:343: warning: incompatible implicit declaration of built-in
function 'cos'
dct-test.c:350: warning: incompatible implicit declaration of built-in
function 'sqrt'
dct-test.c:393: warning: implicit declaration of function 'rint'
dct-test.c:393: warning: incompatible implicit declaration of built-in
function 'rint'
I can work around this by adding an include for math.h.
What environment are you compiling on? It works fine here on x86,
Debian stable.
This is OSX 10.4.9. I think Linux sort-of automatically includes most
math.h functions with other standard headers, so Linux doesn't really
need include math.h. I think it's proper to add the include for
portability reasons.
It compiles fine for me on OS X 10.4.x (don't remember which x offhand)
on my PowerBook...
Post by Ronald S. Bultje
Post by Diego Biurrun
Post by Ronald S. Bultje
dsputil.h:688: warning: implicit declaration of function 'ST16'
dsputil.h:688: warning: implicit declaration of function 'LD16'
dsputil.h:699: warning: implicit declaration of function 'ST32'
dsputil.h:699: warning: implicit declaration of function 'LD32'
fft-test.c:129: warning: implicit declaration of function 'random'
fft-test.c:161: warning: implicit declaration of function 'exit'
fft-test.c:161: warning: incompatible implicit declaration of built-in
function 'exit'
fft-test.c:198: warning: implicit declaration of function 'atoi'
fft-test.c:249: warning: implicit declaration of function 'memcpy'
fft-test.c:249: warning: incompatible implicit declaration of built-in
function 'memcpy'
fft-test.c:276: warning: incompatible implicit declaration of built-in
function 'memcpy'
I can work around this by adding includes for stdlib.h and string.h to
fft-test.c.
gcc -Wl,--warn-common -Wl,--as-needed
-Wl,-rpath-link,"/usr/src/ffmpeg"/libavcodec
-Wl,-rpath-link,"/usr/src/ffmpeg"/libavformat
-Wl,-rpath-link,"/usr/src/ffmpeg"/libavutil -o fft-test fft-test.o
libavcodec.a mdct.o fft.o -L"/usr/src/ffmpeg"/libavutil -lavutil -lm -lz
^^^^^^^^^^^^ ^^^^^^ ^^^^^
Post by Diego Biurrun
/usr/src/ffmpeg/libavcodec/mdct.c:133: multiple definition of `ff_mdct_calc'
libavcodec.a(mdct.o):/usr/src/ffmpeg/libavcodec/mdct.c:133: first defined here
/usr/src/ffmpeg/libavcodec/mdct.c:173: multiple definition of `ff_mdct_end'
libavcodec.a(mdct.o):/usr/src/ffmpeg/libavcodec/mdct.c:173: first defined here
/usr/src/ffmpeg/libavcodec/mdct.c:32: multiple definition of `ff_mdct_init'
libavcodec.a(mdct.o):/usr/src/ffmpeg/libavcodec/mdct.c:32: first defined here
/usr/src/ffmpeg/libavcodec/mdct.c:81: multiple definition of `ff_imdct_calc'
libavcodec.a(mdct.o):/usr/src/ffmpeg/libavcodec/mdct.c:81: first defined here
/usr/src/ffmpeg/libavcodec/fft.c:162: multiple definition of `ff_fft_calc_c'
libavcodec.a(fft.o):/usr/src/ffmpeg/libavcodec/fft.c:162: first defined here
/usr/src/ffmpeg/libavcodec/fft.c:239: multiple definition of `ff_fft_permute'
libavcodec.a(fft.o):/usr/src/ffmpeg/libavcodec/fft.c:239: first defined here
/usr/src/ffmpeg/libavcodec/fft.c:257: multiple definition of `ff_fft_end'
libavcodec.a(fft.o):/usr/src/ffmpeg/libavcodec/fft.c:257: first defined here
/usr/src/ffmpeg/libavcodec/fft.c:34: multiple definition of `ff_fft_init'
libavcodec.a(fft.o):/usr/src/ffmpeg/libavcodec/fft.c:34: first defined here
collect2: ld returned 1 exit status
make: *** [fft-test] Error 1
You're including fft.o/mdct.o twice, once manually and once through
libavcodec.a.
Yes, thanks for pointing out the obvious, fixed.
Post by Ronald S. Bultje
Oh, did I mention I don't use the ffmpeg build system?
Maybe I should include patches to that in my next patch so that it
actually builds for you guys, also. :-).
Haha, we still have more tests compiling than you ;-p
Post by Ronald S. Bultje
Post by Diego Biurrun
Post by Ronald S. Bultje
--- ffmpeg.orig/libavcodec/dct-test.c 2007-03-22 01:00:46.000000000 -0400
+++ ffmpeg/libavcodec/dct-test.c 2007-05-21 09:28:31.000000000 -0400
@@ -39,8 +40,6 @@
#define MAX(a, b) (((a) > (b)) ? (a) : (b))
#endif
-#undef printf
Probably wrong.
Post by Ronald S. Bultje
--- ffmpeg.orig/libavcodec/motion_test.c 2007-03-22 01:00:50.000000000 -0400
+++ ffmpeg/libavcodec/motion_test.c 2007-05-21 09:06:35.000000000 -0400
@@ -31,24 +31,24 @@
-#undef printf
dito
If I remove HAVE_AV_CONFIG_H, the #undef printf becomes unneeded, it's
solely there because we define HAVE_AV_CONFIG_H, which defines printf to
please_use_av_log or so. Michael suggested to get rid of
HAVE_AV_CONFIG_H, which makes the undef unneeded. I'll put this stuff in
several smaller patches which are better-documented and hopefully
prevent confusion, sorry for now...
Could the removal of HAVE_AV_CONFIG_H possibly be the reason for all
your compilation failures?

And yes, please send small, self-contained patches, they will likely all
get applied.

Diego
Diego Biurrun
2007-06-09 17:58:45 UTC
Permalink
Post by Ronald S. Bultje
For reference, new patch attached. If you like it, I'll split it in
whatever way you prefer and submit parts.
--- ffmpeg.orig/libavcodec/motion_test.c 2007-03-22 01:00:50.000000000 -0400
+++ ffmpeg/libavcodec/motion_test.c 2007-05-21 09:06:35.000000000 -0400
@@ -31,24 +31,24 @@
-int pix_abs16x16_mmx(uint8_t *blk1, uint8_t *blk2, int lx);
-int pix_abs16x16_mmx1(uint8_t *blk1, uint8_t *blk2, int lx);
-int pix_abs16x16_c(uint8_t *blk1, uint8_t *blk2, int lx);
-int pix_abs16x16_x2_mmx(uint8_t *blk1, uint8_t *blk2, int lx);
-int pix_abs16x16_x2_mmx1(uint8_t *blk1, uint8_t *blk2, int lx);
-int pix_abs16x16_x2_c(uint8_t *blk1, uint8_t *blk2, int lx);
-int pix_abs16x16_y2_mmx(uint8_t *blk1, uint8_t *blk2, int lx);
-int pix_abs16x16_y2_mmx1(uint8_t *blk1, uint8_t *blk2, int lx);
-int pix_abs16x16_y2_c(uint8_t *blk1, uint8_t *blk2, int lx);
-int pix_abs16x16_xy2_mmx(uint8_t *blk1, uint8_t *blk2, int lx);
-int pix_abs16x16_xy2_mmx1(uint8_t *blk1, uint8_t *blk2, int lx);
-int pix_abs16x16_xy2_c(uint8_t *blk1, uint8_t *blk2, int lx);
+int pix_abs16x16_mmx(void *v, uint8_t *blk1, uint8_t *blk2, int lx, int h);
+int pix_abs16x16_mmx1(void *v, uint8_t *blk1, uint8_t *blk2, int lx, int h);
+int pix_abs16x16_c(void *v, uint8_t *blk1, uint8_t *blk2, int lx, int h);
+int pix_abs16x16_x2_mmx(void *v, uint8_t *blk1, uint8_t *blk2, int lx, int h);
+int pix_abs16x16_x2_mmx1(void *v, uint8_t *blk1, uint8_t *blk2, int lx, int h);
+int pix_abs16x16_x2_c(void *v, uint8_t *blk1, uint8_t *blk2, int lx, int h);
+int pix_abs16x16_y2_mmx(void *v, uint8_t *blk1, uint8_t *blk2, int lx, int h);
+int pix_abs16x16_y2_mmx1(void *v, uint8_t *blk1, uint8_t *blk2, int lx, int h);
+int pix_abs16x16_y2_c(void *v, uint8_t *blk1, uint8_t *blk2, int lx, int h);
+int pix_abs16x16_xy2_mmx(void *v, uint8_t *blk1, uint8_t *blk2, int lx, int h);
+int pix_abs16x16_xy2_mmx1(void *v, uint8_t *blk1, uint8_t *blk2, int lx, int h);
+int pix_abs16x16_xy2_c(void *v, uint8_t *blk1, uint8_t *blk2, int lx, int h);
I think all of this is unnecessary, you can just remove the
declarations, since ...
Post by Ronald S. Bultje
@@ -151,9 +155,25 @@
- test_motion("mmx", pix_abs16x16_mmx, pix_abs16x16_c);
- test_motion("mmx_x2", pix_abs16x16_x2_mmx, pix_abs16x16_x2_c);
- test_motion("mmx_y2", pix_abs16x16_y2_mmx, pix_abs16x16_y2_c);
- test_motion("mmx_xy2", pix_abs16x16_xy2_mmx, pix_abs16x16_xy2_c);
+#ifdef HAVE_MMX
+ ctx = avcodec_alloc_context();
+ mm_flags = 0;
+ dsputil_init(&c, ctx);
+ mm_flags = MM_MMX;
+ dsputil_init(&mmx, ctx);
+
+ test_motion("mmx/16", mmx.pix_abs[0][0], c.pix_abs[0][0]);
+ test_motion("mmx_x2/16", mmx.pix_abs[0][1], c.pix_abs[0][1]);
+ test_motion("mmx_y2/16", mmx.pix_abs[0][2], c.pix_abs[0][2]);
+ test_motion("mmx_xy2/16", mmx.pix_abs[0][3], c.pix_abs[0][3]);
+
+ test_motion("mmx/8", mmx.pix_abs[1][0], c.pix_abs[1][0]);
+ test_motion("mmx_x2/8", mmx.pix_abs[1][1], c.pix_abs[1][1]);
+ test_motion("mmx_y2/8", mmx.pix_abs[1][2], c.pix_abs[1][2]);
+ test_motion("mmx_xy2/8", mmx.pix_abs[1][3], c.pix_abs[1][3]);
+
+ av_free(ctx);
+#endif
... you nuke all occurrences here.

Diego
Diego Biurrun
2007-05-21 22:33:21 UTC
Permalink
Post by Ronald S. Bultje
Post by Diego Biurrun
Post by Ronald S. Bultje
first, sorry for the threading, if you know of a way to fix that in
digest mode, please let me know...
Not use digest mode? Try gmane if the volume of ffmpeg-devel drowns
you.
Let's see how this works. I tried webinterface, didn't work (too much
quoted text, no attachments), then tried nntp: with xnntp, didn't work
(couldn't send emails, or well it said it did, but it never actually
did, I think - maybe you'll get this message 10 times eventually), so
now I'm trying MT_NewsWatcher. Maybe this works. Let me know if
threading is OK now.
Threading is OK now, thank you.
Post by Ronald S. Bultje
Post by Diego Biurrun
Post by Ronald S. Bultje
--- ffmpeg.orig/libavcodec/imgresample.c 2007-03-22 01:00:47.000000000 -0400
+++ ffmpeg/libavcodec/imgresample.c 2007-03-22 01:20:53.000000000 -0400
<at> <at> -28,8 +28,10 <at> <at>
#include "swscale.h"
#include "dsputil.h"
-#ifdef USE_FASTMEMCPY
-#include "libvo/fastmemcpy.h"
+#ifdef TEST
+#undef printf
+#undef fprintf
+#define av_log(p,l,...) fprintf(stderr,__VA_ARGS__)
#endif
Removing the #include is pointless, the rest is probably OK.
So, I may remember this wrong, but I think the consensus a while ago
(there was a "discussion" on this way back) was that this didn't really
belong in ffmpeg, since it's mplayer-specific (see e.g "libvo/"). Other
similar mplayer-specific code (e.g. the fourcc hacks in wav/avi) has
also been removed in ffmpeg. In this case, mplayer could simply use
-include fastmemcpy.h (similar to how the linux kernel does this kind of
stuff) or change the sources if they want this. I've left it in for now,
feel free to remove it (a similar line is in swscale/rgb2rgb.c).
Are you confusing C with Makefile syntax? I know '-include' from
Makefiles only ...

And yes, we possibly could remove the fastmemcpy #includes.
Post by Ronald S. Bultje
Post by Diego Biurrun
Post by Ronald S. Bultje
--- ffmpeg.orig/libavcodec/allcodecs.c 2007-03-22 01:00:46.000000000 -0400
+++ ffmpeg/libavcodec/allcodecs.c 2007-03-22 01:20:53.000000000 -0400
<at> <at> -96,7 +96,9 <at> <at>
REGISTER_ENCDEC (MJPEG, mjpeg);
REGISTER_DECODER(MJPEGB, mjpegb);
REGISTER_DECODER(MMVIDEO, mmvideo);
+#ifdef HAVE_XVMC
REGISTER_DECODER(MPEG_XVMC, mpeg_xvmc);
+#endif
We were glad to get rid of these. It seems our configure does have a
feature or two more than yours after all ...
Probably. I'll be honest here, I'm not yet very interested in adding
support for this, since A) the patch will never be accepted upstream
anyway and B) it's a fair piece of work with no gain at all since I
don't use it. For those part (ext. libs etc.) where I need it, I
re-added the compile conditionals to make it compile. It's not hard to
add it, and the patch would probably still be smaller (don't forget that
the patch w/o compile conditionals was smaller than ffmpeg's system
without compile conditionals also), I just don't want to spend the time
unless I feel it'll be useful. Essentially, I'll add it if there's a
chance that it goes upstream. I don't think that'll happen.
Alternatively, if I see a reason to use it, I'll add it also (and then
the above part of the patch will disappear).
Your line count comparison is not fair since our build system is more
featureful than yours. To compare evenly you have to trim ours down to
your feature set. At least a third of configure would go away then...
Post by Ronald S. Bultje
Anyway, on to the relevant part of the patch for you. Attached, or if
that doesn't work on
http://people.freedesktop.org/~rbultje/ffmpeg_nommx.patch (still
testing...), you'll find those parts of the patch that you referenced
that I should submit separately. The patch does a bunch of things. First
of all, the gains: it allows most of the tests to be compiled (by
Well, the tests compile and link for me, with the exception of
motion-test and fft-test ...
Post by Ronald S. Bultje
--- ffmpeg.orig/tests/dsptest.c 2007-03-22 01:00:52.000000000 -0400
+++ ffmpeg/tests/dsptest.c 2007-05-20 12:50:47.000000000 -0400
@@ -20,18 +20,18 @@
#include "avcodec.h"
#include "dsputil.h"
#include "mpegvideo.h"
-#include "mpeg12data.h"
-#include "mpeg4data.h"
-#include "../libavcodec/i386/cputest.c"
-#include "../libavcodec/i386/dsputil_mmx.c"
-
-#include "../libavcodec/i386/fdct_mmx.c"
-#include "../libavcodec/i386/idct_mmx.c"
-#include "../libavcodec/i386/motion_est_mmx.c"
-#include "../libavcodec/i386/simple_idct_mmx.c"
-#include "../libavcodec/dsputil.c"
-#include "../libavcodec/simple_idct.c"
-#include "../libavcodec/jfdctfst.c"
+//#include "mpeg12data.h"
+//#include "mpeg4data.h"
+#include "i386/cputest.c"
+#include "i386/dsputil_mmx.c"
+
+#include "i386/fdct_mmx.c"
+#include "i386/idct_mmx.c"
+#include "i386/motion_est_mmx.c"
+#include "i386/simple_idct_mmx.c"
+#include "dsputil.c"
+#include "simple_idct.c"
+#include "jfdctfst.c"
This part is already committed, without the i386, which is unneeded.
Post by Ronald S. Bultje
--- ffmpeg.orig/libavcodec/i386/h264dsp_mmx.c 2007-03-22 01:00:40.000000000 -0400
+++ ffmpeg/libavcodec/i386/h264dsp_mmx.c 2007-05-20 12:13:28.000000000 -0400
@@ -1374,7 +1374,7 @@
H264_MC(avg_, 4, mmx2)
H264_MC(avg_, 8, mmx2)
H264_MC(avg_, 16,mmx2)
-
+#undef H264_MC
#define H264_CHROMA_OP(S,D)
#define H264_CHROMA_OP4(S,D,T)
@@ -1514,4 +1514,4 @@
H264_WEIGHT( 4, 8)
H264_WEIGHT( 4, 4)
H264_WEIGHT( 4, 2)
-
+#undef H264_WEIGHT
What is this for?
Post by Ronald S. Bultje
--- ffmpeg.orig/libswscale/cs_test.c 2007-03-22 01:00:59.000000000 -0400
+++ ffmpeg/libswscale/cs_test.c 2007-03-22 09:03:57.000000000 -0400
@@ -23,7 +23,9 @@
#include <unistd.h>
#include <stdlib.h>
#include <inttypes.h>
+#ifdef HAVE_MALLOC_H
#include <malloc.h>
+#endif
#include "swscale.h"
#include "rgb2rgb.h"
This hunk is not against HEAD, the malloc.h #include is no longer there.

Diego
Diego Biurrun
2007-05-16 10:04:25 UTC
Permalink
Post by Ronald S. Bultje
Post by Diego Biurrun
IMHO it's just a lot easier to let it all be done automatically by
using auto* than doing it all manually. A quick wc - l/-c shows that
my Makefile.ams + configure.ac are currently +/- 2250 lines or 48000
bytes - how much is ffmpeg's configure + Makefile?
Where are they?
Google for autotools.patch, or attached. (And forgive me if the Mac
mailer breaks attachments also, I'm expecting that it will.)
I fail to see the advantage of this patch since you are just duplicating
a subset of the features of our build system. Probably you should just
have a look at what the other Diego did for xine instead.

Diego
Continue reading on narkive:
Loading...