this is certainly not the most beautifull but it should work without -fomit-frame-pointer and PIC and gcc-4 vomits when ebp is given in a constraint directly even with -fomi-frame-pointer so theres not that much choice ...
if anyone knows a simpler/cleaner solution, dont hesitate to suggest it ...
Originally committed as revision 18393 to svn://svn.mplayerhq.hu/mplayer/trunk/postproc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27006
This bug caused certain movies (444P or RGB/BGR-based) to become brighter
and more purple when played on a YV12 vo.
Originally committed as revision 18047 to svn://svn.mplayerhq.hu/mplayer/trunk/postproc
was fixed in rgb32to16 about a year ago: using only the first 8 bits of the
32-bit pixel.
Originally committed as revision 17671 to svn://svn.mplayerhq.hu/mplayer/trunk/postproc
once when the scaler is initialized, instead of building them and freeing
them over and over. This gives massive performance improvements.
patch by Alan Curry, pacman*at*TheWorld*dot*com
Originally committed as revision 17589 to svn://svn.mplayerhq.hu/mplayer/trunk/postproc
patch replaces '()' for the correct '(void)' in function
declarations/prototypes which have no parameters. The '()' syntax tell
thats there is a variable list of arguments, so that the compiler cannot
check this. The extra CFLAG '-Wstrict-declarations' shows those cases.
Comments about a similar patch applied to ffmpeg:
That in C++ these mean the same, but in ANSI C the semantics are
different; function() is an (obsolete) K&R C style forward declaration,
it basically means that the function can have any number and any types
of parameters, effectively completely preventing the compiler from doing
any sort of type checking. -- Erik Slagter
Defining functions with unspecified arguments is allowed but bad.
With arguments unspecified the compiler can't report an error/warning
if the function is called with incorrect arguments. -- Måns Rullgård
Originally committed as revision 17567 to svn://svn.mplayerhq.hu/mplayer/trunk/postproc
do the opposite of what they say.
The vec_mstrgb24 and vec_mstbgr24 macros should be opposites and not perform
the same things.
patch by Alan Curry, pacman_at_world_dot_std_dot_com
Originally committed as revision 17564 to svn://svn.mplayerhq.hu/mplayer/trunk/postproc
outputs RGBA. This patch supports 6 output formats and prints an error message
if it is asked to provide an output format it is not capable of.
patch by Alan Curry, pacman_at_world_dot_std_dot_com
Originally committed as revision 17561 to svn://svn.mplayerhq.hu/mplayer/trunk/postproc
sizes based on the image width instead of height.
patch by Alan Curry, pacman at world dot std dot com
Originally committed as revision 17558 to svn://svn.mplayerhq.hu/mplayer/trunk/postproc
bit systems.
Also fixes several crashes because (long)-i is incorrect if i is unsigned.
Originally committed as revision 16740 to svn://svn.mplayerhq.hu/mplayer/trunk/postproc
cleanup by me
indention fixed
second one must be yv12touyvy instead of yv12toyuy2
replace slow modulo by bitwise and
move %16!=0 code before the comment saying the code cant handle %16!=0
Originally committed as revision 15825 to svn://svn.mplayerhq.hu/mplayer/trunk/postproc
tested with gcc-2.95, 3.3, 3.4, 4.0 on ia-32 and 3.4, 4.0, 3.3 on amd64
Originally committed as revision 15763 to svn://svn.mplayerhq.hu/mplayer/trunk/postproc
cast should never have worked. Tested on PowerPC and fixes the black GUI
to show the content.
patch by Rene Rebe <rene at exactcode dot de>
Originally committed as revision 14983 to svn://svn.mplayerhq.hu/mplayer/trunk/postproc
- Fixed PlanarToNV12Wrapper() and made it handle NV21.
- Added yuv2nv12XinC() to handle software scaling.
- Added NV12/NV21 handling to various places.
- Removed NV12 from vf_hue and vf_spp as they don't look like they can
actually handle it.
Originally committed as revision 14716 to svn://svn.mplayerhq.hu/mplayer/trunk/postproc
