summaryrefslogtreecommitdiffstats
path: root/osdep
<
Commit message (Collapse)AuthorAgeFilesLines
* win32: pthread: define PTHREAD_MUTEX_ERRORCHECKwm42020-03-191-0/+1
| | | | mpv uses it now. Doesn't need to do anything.
* osdep: add a pthread debugging wrapperwm42020-03-182-1/+82
| | | | | | | | | | | | | | | | | | | | Because pthread failures are virtually undebuggable (which sure is pretty strange, given all these heavy instrumentation tools these days). Of course it affects only files which include osdep/threads.h. I'm departing from the usual way to add symbols with config.h and using "#if", and defining it on the compiler command line + "#ifdef" because I don't want to include config.h from a header (which would be necessary in this case) to keep things slightly cleaner. Maybe this is misguided, but still. This would have been easier if mpv defined its own wrappers for all thread functions. But we don't (which to be honest is probably better than e.g. going crazy like VLC and essentially reimplementing everything). This seems to be a good compromise. Since it's off by default and basically a developer tool, the minor undefined behavior (redefining reserved symbols) isn't much of an issue.
* options: change option macros and all option declarationswm42020-03-181-24/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Change all OPT_* macros such that they don't define the entire m_option initializer, and instead expand only to a part of it, which sets certain fields. This requires changing almost every option declaration, because they all use these macros. A declaration now always starts with {"name", ... followed by designated initializers only (possibly wrapped in macros). The OPT_* macros now initialize the .offset and .type fields only, sometimes also .priv and others. I think this change makes the option macros less tricky. The old code had to stuff everything into macro arguments (and attempted to allow setting arbitrary fields by letting the user pass designated initializers in the vararg parts). Some of this was made messy due to C99 and C11 not allowing 0-sized varargs with ',' removal. It's also possible that this change is pointless, other than cosmetic preferences. Not too happy about some things. For example, the OPT_CHOICE() indentation I applied looks a bit ugly. Much of this change was done with regex search&replace, but some places required manual editing. In particular, code in "obscure" areas (which I didn't include in compilation) might be broken now. In wayland_common.c the author of some option declarations confused the flags parameter with the default value (though the default value was also properly set below). I fixed this with this change.
* options: introduce bool option type, use it for --fullscreenwm42020-03-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The option code is very old and was added to MPlayer in the early 2000s, when C99 was still new. MPlayer did not use the "bool" type anywhere,l and the logical option equivalent to bool, the "flag" option type, used int, with the convention that only the values 0 and 1 are allowed. mpv may have hammered many, many additional tentacles to the option code, but some of the basics never changed, and m_option_type_flag still uses int. This seems a bit weird, since mpv uses bool for booleans. So finally introduce an m_option_type_bool. To avoid duplicating too much code, change the flag code to bool, and "reimplement" m_option_type_flag on top of m_option_type_bool. As a "demonstration", change the --fullscreen option to this new type. Ideally, all options would be changed too bool, and m_option_type_flag would be removed. But that is a lot of monotonous thankless work, so I'm not doing it, and making it a painful years long transition. At the same time, I'm introducing a new concept for option declarations. Instead of OPT_BOOL(), which define the full m_option struct contents, there's OPTF_BOOL(), which only takes the option field name itself. The name is provided via a normal struct field initializer. Other fields (such as flags) can be provided via designated initializers. The advantage of this is that we don't need tons of nested vararg macros. We also don't need to deal with 0-sized varargs being a pain (and in fact they are not a thing in standard C99 and probably C11). There is no need to provide a mandatory flags argument either, which is the reason why so many OPT_ macros are used with a "0" argument. (The flag argument seems to confuse other developers; they either don't immediately recognize what it is, and sometimes it's supposed to be the option's default value.) Not having to mess with the flag argument in such option macros is also a reason for the removal of M_OPT_RANGE etc., for the better or worse. The only place that special-cased the _flag option type was in command.c; change it to use something effectively very similar that automatically includes the new _bool option type. Everything else should be transparent to the change. The fullscreen option change should be transparent too, as C99 bool is basically an integer type that is clamped to 0/1 (except in Swift, Swift sucks).
* atomic: add atomic_exchange_explicit() fallbackwm42020-03-051-2/+7
| | | | | Apparently I want to use this in a later commit. Untested, because this is a pre-C11 fallback, and I only test with real <stdatomic.h>.
* mac, cocoa: fix UI updates on none main queue threadsder richter2020-02-221-3/+7
| | | | | | injecting the Apple Main Thread Checker via DYLD_INSERT_LIBRARIES=libMainThreadChecker.dylib identified several problems that needed fixing.
* mac: fix media key support for libmpv usersder richter2020-02-225-43/+33
| | | | | | | | this basically moves the remote command center to our mac events instead of keeping it our Application, which is only available when started from mpv itself. also make it independent of the NSApplication. this also prevents a runtime crash
* scripting: add a way to run sub processes as "scripts"wm42020-02-191-0/+6
| | | | | | | | | | This is just a more convenient way to start IPC client scripts per mpv instance. Does not work on Windows, although it could if the subprocess and IPC parts are implemented (and I guess .exe/.bat suffixes are required). Also untested whether it builds on Windows. A lot of other things are untested too, so don't complain.
* subprocess: implement proper detached processes on POSIXwm42020-02-163-10/+66
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The previous method for this sucked: for every launched detached process, it started a thread, which then would leak if the launched process didn't end before the player uninitialized. This was very racy (although I bet the race condition wouldn't trigger in a 100 years), and wasteful (threads aren't a cheap resource). Implement it for POSIX directly. posix_spawn() has no direct support for this, so we need to do it ourselves with fork(). We could probably do it without fork(), and attempt to collect the PID in another thread. But then we'd either have a waiting thread again, or we'd need to do an unsafe waitpid(-1, ...) call. (POSIX process management sucks so badly, how did they even manage this. Hopefully I'm just missing something, but I'm not.) So now we depend on both posix_spawn() _and_ fork(), isn't it fun? Also call setsid(), to essentially detach the child process from the terminal. (Otherwise it can receive various signals from the terminal, which is probably not what you want.) posix_spawn() adds POSIX_SPAWN_SETSID in newer POSIX releases, but we don't want to rely on this yet. The posix_spawnp() call is duplicated, but this is better than somehow trying to unify the code paths. Only somewhat tested, so enjoy the bugs.
* subprocess: change to a fancier APIwm42020-02-163-83/+185
| | | | | | | | | | | | | | Introduce mp_subprocess() and related definitions. This is a bit more flexible than the old stuff. This may or may not be used for a more complicated feature that involves starting processes, and which would require more control. Only port subprocess-posix.c to this API. The player still uses the "old" API, so for win32 and dummy implementations, the new API is simply not available, while for POSIX, the old APIs are emulated on top of the new one. I'm hoping the win32 code can be ported as well, so the ifdefs in subprocess.c can be dropped, and the player can (if convenient or needed) use the new API.
* mac: activate logging when started from the bundleder richter2020-02-081-4/+41
| | | | | | | | | | this creates a default log for the last mpv run when started from the bundle. that way one can get a log of what happened even after an issue occurred. also add a menu entry under Help to show the current log, but only when the bundle is used. Fixes #7396 Fixes #2547
* mac: remove stdout and stderr redirect for loggingder richter2020-02-081-11/+0
| | | | | | | this was kinda useless anyway since the bundle was started with terminal=no and no logging was done anyway. Fixes #1590
* mac: change Report Issue menu link to the new choose template pageder richter2020-01-261-1/+1
|
* cocoa-cb: add support for forcing the dedicated GPU for renderingder richter2020-01-262-0/+4
| | | | | | | | this deprecates the old cocoa backend only option and moves it to the general macos ones. add support for the new option in the cocoa-cb layer creation and use the new option in the olde cocoa backend. Fixes #7272
* mac: report playback state to the MediaPlayer Command Centerder richter2020-01-262-11/+48
| | | | | | some system logic for the global media key events depends on the right playback state. set the state properly to prevent more breakages in the future.
* mac: add support for PLAYONLY and PAUSEONLY key codes to MediaPlayerder richter2020-01-261-3/+3
| | | | Fixes #7365
* build: fix build with disabled swift and Media Playerder richter2019-12-231-1/+2
| | | | | | | | | | | | | | when swift is disabled some headers are not included. one of them is the options/options.h header that is needed for the vo_sub_opts struct. we include it to fix the build without swift. the second problem is the build time check for the macOS 10.12.2 features or more specific the Media Player support. since it is a swift feature we can not use it when swift is disabled. add a separate Media Player check that also depends on swift and use that new preprocessor variable as a build time check instead. Fixes #7282
* mac: replace old event tap for media key support with MediaPlayerder richter2019-12-156-126/+184
| | | | | | | | | | | | | | | the old event tap has several problems, like no proper priority support or having to set accessibility permissions for mpv or the terminal. it is now replaced by the new MediaPlayer which has proper priority support and isn't as greedy as previously. this only includes Media Key support and not any of the other features included in the MediaPlayer framework, like proper Now Playing data (only set dummy data for now). this is only available on macOS 10.12.2 and higher. also removes some unnecessary redefines. Fixes #6389
* mac: remove Apple Remote supportder richter2019-12-155-2481/+1
| | | | | | the Apple Remote has long been deprecated and abandoned by Apple. current macs don't come with support for it anymore. support might be re-added with the next commit.
* cocoa-cb: fix freeing of macos_opts config groupder richter2019-12-151-5/+5
| | | | | | | | | using the MPContext as ta parent was a bad idea and shouldn't be done in any circumstances there because it only supposed to be for internal usage. this had the undesired effect that the options group was freed but still used since the MPContext is freed afterwards. instead manually free options group.
* cocoa-cb: update and add more options to use new options handlingder richter2019-12-151-0/+5
| | | | | this updates and add the maximized, minimized, keepaspect and ontop options to use the new options handling
* cocoa-cb: use m_config_cache and new VOCTRL for option handlingder richter2019-12-154-5/+49
| | | | | | | | this removes the direct access of the mp_vo_opts stuct via the vo struct and replaces it with the m_config_cache usage. this updates the fullscreen and window-minimized property via m_config_cache_write_opt instead of the old mechanism via VOCTRL and event flagging. also use the new VOCTRL_VO_OPTS_CHANGED event for fullscreen and border changes.
* atomic: add mp_atomic_uint64wm42019-11-291-0/+2
|
* player: Optionally validate st_mtime when restoring playback stateChris Down2019-11-201-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I often watch sporting events. On many occasions I get files with the same filename for each session. For example, for F1 I might have the following directory structure: F1/ FP1.mkv FP2.mkv FP3.mkv Qualification.mkv Race.mkv Since usually one simply watches one race after the other, I usually just rsync the new event's files over the old ones, so, for example, Race.mkv will be replaced from the file for the last event with the file from the new event. One problem with this is that I like to use --resume-playback for other kinds of media, so I have it on by default. That works great for, say, a movie, but doesn't work so well with this scheme, because you can trivially forget to pass --no-resume-playback on the command line and end up 2 hours in, watching spoilers as the race results scroll down the screen :-) This patch adds a new option, --resume-playback-check-mtime, which validates that the file's mtime hasn't changed since the watch_later configuration was saved. It does this by setting the watch_later configuration to have the same mtime as the file after it is saved. Switching back and forth between checking mtime and not checking mtime works fine, as we only choose whether to compare based on it, but we update the watch_later configuration mtime regardless of its value.
* cocoa-cb: remove get_property_* usages and split up mpv helperder richter2019-10-065-110/+156
| | | | | | | | | | all the get_property_* usages were removed because in some circumstances they can lead to deadlocks. they were replaced by accessing the vo and mp_vo_opts structs directly, like on other vos. additionally the mpv helper was split into a mpv and libmpv helper, to differentiate between private and public APIs and for future changes like a macOS vulkan context for vo=gpu.
* cocoa-cb: add support for 10bit opengl renderingder richter2019-09-264-1/+20
| | | | | | | this will request a 16bit half-float framebuffer instead if a 8bit integer framebuffer. Fixes #3613
* mac: add Open Playlist menu bar itemAkemi2019-09-231-0/+17
|
* stream_libarchive: Always use LC_CTYPE_MASK for libarchiveJames Hilliard2019-09-211-1/+0
| | | | | | Using LC_ALL_MASK is unnecessary and unreliable on some systems. Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
* io: remove Windows tmpfile() emulationwm42019-09-192-37/+0
| | | | | | | | | | | | Unused now. The old stream cache used it, but it was removed. On a side note, the demuxer cache uses mp_mkostemps(). It looks like our Windows open() emulation handles this correctly by using CREATE_NEW, so no functionality gets lost by the "new" approach. On the other hand, the demuxer cache does not set FILE_FLAG_DELETE_ON_CLOSE, but instead tries to delete the file after opening (POSIX style), which probably won't work on Windows. But I'm not sure how to make it use the DELETE_ON_CLOSE flag, so whatever.
* win32: remove -municode from mpv binarywm42019-09-191-7/+5
| | | | | | | | | | | | | If this is used, the runtime expects that wmain() instead of main() is defined. This caused me severe problems in a certain now irrelevant case. I think it's a good idea to avoid this special case. We can just use main() and call GetCommandLineW() instead. This function returns a single string, so use CommandLineToArgvW() to split it, and hope it has the same semantics. Should this ever return NULL, hope that it leaves argc at 0. Untested, I think.
* osdep: add mkostemps() emulationwm42019-09-192-2/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Supposed to follow the standard function. The standard function is not standard, but a GNU extension. Adding some ifdef mess is pointless too - it has no advantages other than having a mess, and not spotting implementation bugs in the emulation due to running it only on "obscure" platforms (like Windows, so most computers actually, except the developer's platform). There is mkstemp(), which at least is in POSIX 2008. But it's 100% useless, except in some obscure cases: it doesn't set O_CLOEXEC, nor can you pass it to it. Without O_CLOEXEC, we'd leak the temporary file to all child processes. (The fact that the file, which is expected to reach double or tripple digit GB sizes, will be deleted only once all processes unreference the FD, makes this sort of a big deal. You could ftruncate() it, but that doesn't fix all the other problems.) Why did POSIX standardize mkstemp() and O_CLOEXEC apparently at the same time, but provided no way to pass O_CLOEXEC to mkstemp()? With the introduction of O_CLOEXEC, they acknowledged that there's a need to atomically set the FD_CLOEXEC flag when creating file descriptors. (FD_CLOEXEC was standard before that, but setting it with fcntl() is racy.) You're much more likely to need a temp file that is CLOEXEC rather than the opposite, and even if they were somehow opposed to CLOEXEC by default (such as for compat. reasons), surely POSIX could have standardized mkostemp() too or instead. And then there's the fact that this whole O_CLOEXEC mess is stupid. Surely there would have been a better way to handle this, instead of requiring adding O_CLOEXEC to almost ALL instances of open() in all code that has been written ever. The justification for this is that the historic default was wrong, and you can't change it (e.g. this won't work: changing the behavior of exec() and not inherit the FD to the child process, unless a hypothetical O_KEEP_EXEC flag is set). But on the other hand, surely you could have introduced an exec() variant which does close all FDs, except a whitelist of FDs passed to it. Let's call it execve2(). In fact, I'm going to argue that exec() call sites are the most aware of whether (and which) FDs to inherit. Some programs even tried to explicitly iterate over all opened FDs and explicitly close "unwanted" FDs (which of course was problematic for other reasons), and such an execve2() call would have been the ideal solution. Maybe this proposed solution would have had problems too. But surely revisiting and reviewing every exec*() call would have been simpler than reviewing every open() call. And more importantly, having to extend every damn library function that either calls open() or creates FDs in some other way, like mkstemp(). What argument are there going to be against this? That there will be library code that can't keep working correctly with processes that use the "old" exec? Well, what about all my legacy library code that uses open() incorrectly, and that will break no matter what? Well, I'm not going to claim that I can come up with better solutions than POSIX (generally or in this case), but this situation is ABSOLUTELY ATROCIOUS. It makes win32 programming look attractive compared to POSIX, that standard pandering to dead people from the past. (Note: not trying to insult dead people.) I'm not sure what POSIX is even doing. Anything useful? Doesn't look like it to me. Are they paid? Why? They didn't even fix the locale mess, nor do they intend to. I bet they're proud of discussing compatibility to 70ies code day in and day out iwtohut ever producing anything useful. What a load of crap. They seriously got to do better than this. Oh, and my wrapper is probably buggy. Fortunately that doesn't matter. Also I'm dumping this into io.h. Originally, io.h was just supposed to replace broken implementation of standard functions by MinGW (and then by Android), but whatever, just give a dumping ground for shit code.
* cocoa-cb: migrate to swift 5 with swift 4 fallbackder richter2019-07-213-9/+74
| | | | | | | | | | | | | this migrates our current swift code to version 5 and 4. building is support from 10.12.6 and xcode 9.1 onwards. dynamic linking is the new default, since Apple removed static libs from their new toolchains and it's the recommended way. additionally the found macOS SDK version is printed since it's an important information for finding possible errors now. Fixes #6470
* cocoa-cb: conditional compilation for Dark Mode and Material featuresder richter2019-07-211-0/+24
| | | | Fixes #6621
* win32-console-wrapper: silence missing prototype warningsJames Ross-Gowan2019-05-101-2/+4
|
* libarchive: add fallback for systems without C.UTF-8dudemanguy2019-05-041-0/+1
|
* cocoa-cb: remove all force unwrappings of optionalsder richter2019-04-252-25/+37
| | | | | | the force unwrapping of optionals caused many unpredictable segfaults instead of gracefully exiting or falling back. besides that, it is bad practice and the code is a lot more stable now.
* cocoa-cb: add support for custom colored title barder richter2019-04-024-0/+18
|
* cocoa-cb: refactor title bar stylingder richter2019-04-023-3/+20
| | | | | | | | | | | | | half of the materials we used were deprecated with macOS 10.14, broken and not supported by run time changes of the macOS theme. furthermore our styling names were completely inconsistent with the actually look since macOS 10.14, eg ultradark got a lot brighter and couldn't be considered ultradark anymore. i decided to drop the old option --macos-title-bar-style and rework the whole mechanism to allow more freedom. now materials and appearance can be set separately. even if apple changes the look or semantics in the future the new options can be easily adapted.
* cocoa-cb: synchronise the flush with the renderAkemi2019-04-021-1/+4
| | | | | | | this could lead to a crash on deinit when flush was called while the opengl state was cleaned up. Fixes #6323
* cocoa-cb: wakeup vo when new events are availableAkemi2019-04-021-0/+1
| | | | | | | new events were added but not fetched by the vo, because we didn't signal the vo that new events were available. actually wakeup the vo when new events are available.
* macosx_events: fix crash when shutting down during window animationsRodger Combs2019-03-131-1/+3
|
* Merge branch 'master' into pr6360Jan Ekström2019-03-113-1/+67
|\ | | | | | | | | | | Manual changes done: * Merged the interface-changes under the already master'd changes. * Moved the hwdec-related option changes to video/decode/vd_lavc.c.
| * cocoa-cb: add support for VOCTRL_GET_DISPLAY_NAMESAkemi2019-02-102-0/+38
| |
| * cocoa-cb: use Swift Extensions for convenienceAkemi2019-02-101-0/+28
| | | | | | | | preparations for the following commit.
| * mac: add missing semicolon to macosx_compat.hKen2019-01-261-1/+1
| | | | | | | | fixes build on older systems
* | demux, stream: readd cache-speed in some other formwm42018-12-061-0/+3
| | | | | | | | it's more like an input speed rather than a cache speed, but who cares.
* | Merge commit '559a400ac36e75a8d73ba263fd7fa6736df1c2da' into ↵Anton Kindestam2018-12-055-17/+8
|\ \ | |/ |/| | | | | | | wm4-commits--merge-edition This bumps libmpv version to 1.103
| * terminal-unix: stop trying to read when terminal disappearswm42018-05-241-2/+4
| | | | | | | | | | | | | | | | Avoids 100% CPU usage due to terminal code retrying read(). Seems like this was "forgotten" (or there was somehow the assumption poll() would not signal POLLIN anymore). Fixes #5842.
| * osdep: add portable C11-like alignof() macrowm42018-05-241-0/+5
| |