The #warning preprocessor directive is non-standard and not available with all
compilers. Furthermore, the warnings it causes are noisy and have not led to
getting any of the underlying issues fixed in the space of a decade.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@32480 b3059339-0415-0410-9bf9-f77b7e298cf2
This is required for the Expression Screen Codec binary decoder.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@31906 b3059339-0415-0410-9bf9-f77b7e298cf2
Make library/export function tables static const.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@31898 b3059339-0415-0410-9bf9-f77b7e298cf2
Avoid mixing code and declarations.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@31899 b3059339-0415-0410-9bf9-f77b7e298cf2
Make function declarations proper prototypes.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@31900 b3059339-0415-0410-9bf9-f77b7e298cf2
Fix type in conditional.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@31901 b3059339-0415-0410-9bf9-f77b7e298cf2
Avoid arithmetic on void * pointers.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@31902 b3059339-0415-0410-9bf9-f77b7e298cf2
Add const to avoid warnings.
The const on the return type is not correct compared to the real win32 API
functions, but that really does not matter for us, avoiding the warning is
more useful.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@31903 b3059339-0415-0410-9bf9-f77b7e298cf2
DirectShow codec).
Required changes:
- codecs.conf entry (of course).
- Allow opening files with “.col” in the file name, just like “vp3” and “.fpf”
already was allowed. (CineForm expects to be able to do this, presumably
for some color management code.)
- In registry.c, fake a few registry keys that the codec expects the installer
to have written. Also, change a few magic numbers (0, 2) to the appropriate
constants (ERROR_SUCCESS, ERROR_FILE_NOT_FOUND) where appropriate, so the code
is easier to follow.
SMP works fine, but seemingly performs suboptimally (e.g., on my dual-core
laptop, CineForm performs better if I lie to it and tell it I have four cores).
I don't know if this is inherent in the codec, or some inefficiency in the
emulated synchronization primitives.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@31196 b3059339-0415-0410-9bf9-f77b7e298cf2
since it's now statically allocated and will not be reallocated if a new
allocation comes along.
This also fixes an issue where the mutex would not always be properly
unlocked, leading to deadlocks. I thought I'd committed that ages ago,
but obviously not, and it broke CineForm initialization.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30957 b3059339-0415-0410-9bf9-f77b7e298cf2
These files now contain different functions related to path handling.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30943 b3059339-0415-0410-9bf9-f77b7e298cf2
This fixes compilation with the Win32 loader disabled but other binary
codec loaders enabled.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30942 b3059339-0415-0410-9bf9-f77b7e298cf2
It's time we move to 2010: Announce Windows XP SP2 to codecs instead of Win95
OSR2.
Note: We still don't support the *Ex fields in the version info struct
properly (we shouldn't really overwrite the structure size, but rather check
it to see if it's safe to fill the extra fields). No codec I've found seems
to care.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30927 b3059339-0415-0410-9bf9-f77b7e298cf2
Don't hardcode dwNumberOfProcessors=1 for Win32 anymore; the mutex/event code
is still far from perfect, but now good enough that I can't find any codecs
that breaks with this (tested on a quad with various codecs). This tells
codecs they can use more than one core if they want to (some already did, by
launching multiple threads even when told there was only a single core).
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30926 b3059339-0415-0410-9bf9-f77b7e298cf2
InitializeCriticalSectionAndSpinCount returns a nonzero value on success,
and some codecs (notably VP7) seemingly got confused when it didn't, if and
only if we tried to emulate NT or newer.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30913 b3059339-0415-0410-9bf9-f77b7e298cf2
different structure, and CreateMutexW, CreateEventW and CreateSemaphoreW as
simple wrappers around the A versions.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30900 b3059339-0415-0410-9bf9-f77b7e298cf2
Nowadays MPlayer does not use the codecs from other installed programs.
A runtime setting will soon take over the rare case that binary codecs
should be searched for in non-standard directories.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30888 b3059339-0415-0410-9bf9-f77b7e298cf2
Relatively simplistic implementations of ResumeThread (stub) and
SignalObjectAndWait (bAlertable is ignored). Both are needed for ProRes 4:2:2
support on Linux.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30861 b3059339-0415-0410-9bf9-f77b7e298cf2
Implement Win32 mutexes; they used to just be mapped on top of events, which
is not the same thing at all.
The implementation is pretty much the obvious one, similar to the
current critical section implementation and the semaphore implementation;
a single lock count protected by a pthread mutex, and an event lockers can
sleep on to know when the mutex is available.
Also make CreateMutexA and ReleaseMutex available even if QuickTime codecs
support is not configured.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30853 b3059339-0415-0410-9bf9-f77b7e298cf2
Two simple bugfixes for semaphores in WaitForSingleObject:
First, semaphore count should be decreased on loading the semaphore, not
increased. The case for duration=0 had this wrong (duration=-1 was fine).
Second, the code for duration=-1 forgot to set the return value, so it
would always return WAIT_FAILED.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30852 b3059339-0415-0410-9bf9-f77b7e298cf2
loader/win32.c contains a global linked list of all existing mutexes
(whose head is called mlist), which is accessed from multiple threads,
and as such needs to be protected by a mutex. Fixed.
Same thing for the global linked list of all existing threads, whose
head is called list.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30851 b3059339-0415-0410-9bf9-f77b7e298cf2
Some codecs, and more recently Microsoft's CRT library, expect GetModuleHandle(NULL)
to return a pointer to the program's PE header mapped in memory. Thus, just returning
0x0 or 0x1 won't do it anymore, so create a minimal PE header and return that.
Patch originally by Gianluigi Tiesi ( mplayer (at) netfarm (dot) it ).
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30848 b3059339-0415-0410-9bf9-f77b7e298cf2
Some extra changes snuck into my commit; they'll probably be reviewed
and committed to Subversion eventually, but were not part of the fix
for WaitForSingleObject on thread handles.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30844 b3059339-0415-0410-9bf9-f77b7e298cf2
Some codecs need this for clean shutdown (as opposed to a crash); we don't
really support timed wait since POSIX doesn't, but it doesn't seem necessary.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30843 b3059339-0415-0410-9bf9-f77b7e298cf2
Earlier, cs->locked was accessed outside the mutex to get around
the problem that default pthread mutexes are not recursive
(ie., you cannot do a double-lock from the same thread), causing
a thread-safety problem, as both detected by Helgrind and showing
up in some multithreaded codecs.
The ideal solution here would be to simply use recursive pthread
mutexes, but there were concerns about reduced debuggability and
possibly portability. Thus, instead, rewrite the critical sections
to be a simple lock count (with owner) protected by a regular mutex.
Whenever a thread wants to enter the critical section and lock_count
is not 0, it sleeps on a special event that tells it when the
critical section is available.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30837 b3059339-0415-0410-9bf9-f77b7e298cf2
CreatePalette had problems for me, and looking at the code it was quite
obvious why; someone had reversed the order of the two elements of the
LOGPALETTE struct, causing it to allocate and copy a bogus amount of memory.
Why on earth anybody would want to do that is beyond me; whoever did it even
left a comment, but it wasn't very helpful, as it crashed nevertheless. :-)
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30832 b3059339-0415-0410-9bf9-f77b7e298cf2
Events have a “reset” member that specify if they flag is automatically
set back on read/wait. However, this was populated by bManualReset, so the
flag was inverted and once an event was set, it would forever be counted
as so. Fixed by inverting the flag.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30831 b3059339-0415-0410-9bf9-f77b7e298cf2
These were simply inverted compared to what they should be.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30830 b3059339-0415-0410-9bf9-f77b7e298cf2
These functions return void*, which is compatible with any pointer,
so there is no need for casts.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30744 b3059339-0415-0410-9bf9-f77b7e298cf2
Dependencies were only set correctly if the loader code was enabled.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30542 b3059339-0415-0410-9bf9-f77b7e298cf2
Patch by Steinar H. Gunderson [sgunderson bigfoot com]
with some modifications by me.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30531 b3059339-0415-0410-9bf9-f77b7e298cf2
diego
reimar
alexc
compn
sesse