path: root/compat
Commit message (Collapse)AuthorAgeFilesLines
* Move compat/ and bstr/ directory contents somewhere elsewm42014-08-294-160/+0
| | | | | | | | | bstr.c doesn't really deserve its own directory, and compat had just a few files, most of which may as well be in osdep. There isn't really any justification for these extra directories, so get rid of them. The compat/libav.h was empty - just delete it. We changed our approach to API compatibility, and will likely not need it anymore.
* build: allow compilation without any atomicswm42014-07-051-2/+13
| | | | | | | | | | | | | | | | | | | Not all compilers on all platforms have atomics available (even if they could, technically speaking). We don't use atomics that much, only the following things rely on it: 1. the audio pull code, and all audio outputs using it 2. updating global msg levels 3. reading log messages through the client API Just disable 1. and 3. if atomics are not available. For 2., using fake- atomics isn't too bad; at worst, message levels won't properly update under certain situations (but most likely, it will work just fine). This means if atomics are not available, the client API function mpv_request_log_messages() will do nothing. CC: @mpv-player/stable
* atomics: some corrections to __sync builtins usagewm42014-05-281-3/+3
| | | | | | | | | | | | We don't need to combine __sync_add_and_fetch with a memory barrier, since these intrinsics are documented as using a full barrier already. Use __sync_fetch_and_add instead of __sync_add_and_fetch; this gives atomic_fetch_add() the correct return value (although we don't use it). Use __sync_fetch_and_add to emulate atomic_load(). This should enforce the full barrier semantics better. (This trick is stolen from the FreeBSD based stdatomic.h emulation.)
* atomics: more correct usage of gcc/clang __atomic builtinswm42014-05-211-11/+15
| | | | | | | | | | | This should be more correct. The builtins were made to directly map to C11, and the way we use them is now relatively close to how gcc implements atomics in 4.9. In particular, we make use of the load and store builtins. I'm not entirely sure why gcc didn't support stdatomic.h in 4.8 already. Maybe support for the builtins was incomplete or broken - so there's a lot of room for doubt about the correctness of this.
* atomics: switch to C11 stdatomic.hwm42014-05-211-6/+36
| | | | | | | | | | | | | | | | | | | | | | | | | In my opinion, we shouldn't use atomics at all, but ok. This switches the mpv code to use C11 stdatomic.h, and for compilers that don't support stdatomic.h yet, we emulate the subset used by mpv using the builtins commonly provided by gcc and clang. This supersedes an earlier similar attempt by Kovensky. That attempt unfortunately relied on a big copypasted freebsd header (which also depended on much more highly compiler-specific functionality, defined reserved symbols, etc.), so it had to be NIH'ed. Some issues: - C11 says default initialization of atomics "produces a valid state", but it's not sure whether the stored value is really 0. But we rely on this. - I'm pretty sure our use of the __atomic... builtins is/was incorrect. We don't use atomic load/store intrinsics, and access stuff directly. - Our wrapper actually does stricter typechecking than the stdatomic.h implementation by gcc 4.9. We make the atomic types incompatible with normal types by wrapping them into structs. (The FreeBSD wrapper does the same.) - I couldn't test on MinGW.
* compat/libav: remove unneeded thingswm42014-05-181-8/+1
| | | | | | Currently, it's unused. Still keep the file, because it's not unlikely we'll need it again, and removing/readding the include statements for this file is too annoying.
* Remove CPU detection and inline asm handlingwm42014-04-192-122/+0
| | | | | | | | | | | | | | Not needed anymore. I'm not opposed to having asm, but inline asm is too much of a pain, and it was planned long ago to eventually get rid fo all inline asm uses. For the note, the inline asm use that was removed with the previous commits was almost worthless. It was confined to video filters, and most video filtering is now done with libavfilter. Some mpv filters (like vf_pullup) actually redirect to libavfilter if possible. If asm is added in the future, it should happen in the form of external files.
* Remove some more unneeded version checkswm42014-03-161-12/+0
| | | | | All of these check against things that happened before the latest supported FFmpeg/Libav release.
* build: make configure fail if both __atomic and __sync are not availableStefano Pigozzi2014-01-011-1/+3
* compat: use __atomic operations instead of __sync, when presentAlessandro Ghedini2013-12-311-2/+9
| | | | | Fixes #434 Fixes #437
* Split mpvcore/ into common/, misc/, bstr/wm42013-12-171-0/+23
* compat: add compatibility kludge for Libav 9wm42013-12-081-0/+12
| | | | | | | | Libav 9 still uses the unprefixed PIX_FMT_... symbols, but they will probably be removed some time in the future. There are some other deprecations we have yet to take care of, but there are no clear replacements yet.
* compat: remove an unused symbolwm42013-04-261-4/+0
| | | | | The compatibility issue actually didn#t get solved, it's just handled differently in mpv now.
* configure: bump minimum FFmpeg/Libav versions, remove compat hackswm42013-03-131-13/+0
| | | | | | | | | | | | | | | | | We consider FFmpeg 1.x and Libav 0.9.x releases compatible. Support for FFmpeg 0.9.x and Libav 0.8.x is considered infeasible and has been dropped in the previous commits. The bits that break compatibility are mainly the CodecID renaming (trivial, but would require nasty hacks everywhere), the avcodec_encode_video2() function (missing in older releases, mandatory in newer ones), and the resampler changes (older releases miss lib{av,sw}resample, newer versions removed the libavcodec resampler). Remove some other compatibility bits that were needed to for releases for which we drop support. The comment about Libav 0.9 in compat/libav.h is incorrect and should have been 0.8 (the symbol is present in Libav 0.9).
* Prefix CODEC_ID_ with AV_wm42013-03-131-1/+1
| | | | | | | | | The old names have been deprecated a while ago, but were needed for supporting older ffmpeg/libav versions. The deprecated identifiers have been removed from recent Libav and FFmpeg git. This change breaks compatibility with Libav 0.8.x and equivalent FFmpeg releases.
* build: make it work on somewhat older ffmpeg versionswm42013-01-311-1/+1
| | | | | | Tested with n0.10.4. All these version checks are rather tricky, because Libav and FFmpeg change the same thing at slightly different versions.
* windows support: support 64-bit MS Windows in EXTERN_PREFIX definitionUoti Urpala2013-01-271-1/+1
| | | | | | | | The EXTERN_PREFIX definition changed in 94b7db2 needs a separate case for _WIN64, as MinGW defines both that and _WIN32 but there is no prefix unlike 32-bit case. Patch by redxii on
* Fix compilation with ffmpeg 1.0wm42012-12-131-4/+0
| | | | | AVPROBE_SCORE_RETRY was too new, and doesn't even exist in Libav. Go back to using the value explicitly.
* Fix compilation with Libavwm42012-12-111-0/+10
| | | | | | | | | | Doesn't define AVPROBE_SCORE_RETRY for some reason. They use AVPROBE_SCORE_MAX/4 directly internally. AV_DISPOSITION_ATTACHED_PIC is not defined with the most recent Libav release. AVIOContext.av_class exists in Libav, but is apparently disabled in old releases. Disable it for now until people stop torturing me with old crap releases.
* Improve compatibility with Libav 0.8.4 and ffmpeg 0.11.2wm42012-11-141-1/+5
| | | | | | | | | | | Libav 0.8.4 is ridiculously old (in relative terms), so I don't know how many things are broken silently. Encoding is disabled, because the required API hasn't been added yet. (On the other hand, the old API can't be used in newer versions.) This should improve compatibility with ffmpeg 0.11.2 as well, which didn't define AV_CODEC_ID_SUBRIP yet.
* Add MP_NORETURN and replace av_noreturn useswm42012-11-121-0/+3
| | | | | av_noreturn is a rather recent addition to libavutil, and defining it ourselves is trivial and makes playing compatibility games easier.
* mp_common.h: split parts into mp_talloc.h and compiler.hwm42012-11-121-0/+24
| | | | | | Put MP_EXPAND_ARGS() in compiler.h, even though it's not compiler dependent. Both mp_talloc.h and mp_common.h need it, while mp_common.h includes mp_talloc.h. This is the least annoying solution.
* libav.h: increase compatibility by not including libavutil/version.hwm42012-11-121-1/+0
| | | | | libavutil/version.h was only recently split off from libavutil/avutil.h, and that file includes version.h anyway.
* Rename directories, move files (step 1 of 2) (does not compile)wm42012-11-124-0/+193
Tis drops the silly lib prefixes, and attempts to organize the tree in a more logical way. Make the top-level directory less cluttered as well. Renames the following directories: libaf -> audio/filter libao2 -> audio/out libvo -> video/out libmpdemux -> demux Split libmpcodecs: vf* -> video/filter vd*, dec_video.* -> video/decode mp_image*, img_format*, ... -> video/ ad*, dec_audio.* -> audio/decode libaf/format.* is moved to audio/ - this is similar to how mp_image.* is located in video/. Move most top-level .c/.h files to core. (talloc.c/.h is left on top- level, because it's external.) Park some of the more annoying files in compat/. Some of these are relicts from the time mplayer used ffmpeg internals. sub/ is not split, because it's too much of a mess (subtitle code is mixed with OSD display and rendering). Maybe the organization of core is not ideal: it mixes playback core (like mplayer.c) and utility helpers (like bstr.c/h). Should the need arise, the playback core will be moved somewhere else, while core contains all helper and common code.