summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* cocoa: redo synchronizationwm42015-05-133-169/+156
| | | | | | | | | | | | | | | | | | | | | Before this change, Cocoa state was accessed from both the VO and the Cocoa main thread. This was probably not a good idea. There was some locking as well as implicit synchronization using the dispatch mechanism, but it wasn't watertight. Change this completely. Now Cocoa things are always accessed from the main thread only. The old mutex falls away, as well as the vo_cocoa_set_current_context() function, which implicitly used the lock to coordinate VO accesses. With the new code, the VO thread generally has to wait for the main thread, while the main thread never waits for the VO and rarely accesses it. Fortunately, this is rather straight forward, and most of this is achieved by making vo_cocoa_control() run on the main thread. The logic of the code does generally not change. Some aspects are trickier. Apparently we can't access the NSOpenGLContext from the VO thread, because this object is not thread- safe. We use some CGLContextObj functions instead, such as for making the context current and swapping the buffers.
* vo_opengl: remove some more Cocoa resize leftoverswm42015-05-134-31/+0
|
* manpage: explain some property expansion restrictionswm42015-05-131-1/+4
|
* manpage: remove stray newlinewm42015-05-131-1/+0
|
* vda: add support for nv12 image formatsStefano Pigozzi2015-05-133-21/+115
| | | | | | | | | The hardware always decodes to nv12 so using this image format causes less cpu usage than uyvy (which we are currently using, since Apple examples and other free software use that). The reduction in cpu usage can add up to quite a bit, especially for 4k or high fps video. This needs an accompaning commit in libavcodec.
* build: check for lua52Christian Hesse2015-05-131-0/+1
| | | | | | | Arch linux is about to update to lua 5.3.x, but lua 5.2.x will be provided by package lua52, which contains pkg-config file lua52.pc. Signed-off-by: wm4 <wm4@nowhere>
* vo: avoid burning CPU when pausedwm42015-05-131-1/+2
| | | | | | Some code always calls vo_event(), even with event==0, which leads to immediate wakeup, which in turn causes the function to be called again. This would burn CPU, which was especially noticeable when paused.
* win32: add mappings for some special keyswm42015-05-121-0/+9
| | | | Untested.
* ipc: avoid SIGPIPEwm42015-05-121-1/+5
| | | | | | | | | Until now, we just blocked SIGPIPE globally. Fix it properly to get away from it. MSG_NOSIGNAL should be widely available and is part of the POSIX.1-2008 standard. But it's not available on OSX, because Apple is both evil and retarded. Thus we continue to ignore the problem on such shitty systems.
* cocoa: make live-resizing as fast as beforewm42015-05-123-9/+14
| | | | | | | | | | | Interrupt video timing. This means the Cocoa event loop does not have to up to 2 video frame durations until redrawing the frame finally has finished. We abuse the VO event flags for this. Eventually this should use wait_vo() or so in the video timing wait function, but for now the interaction this would require with the code of other VOs/backends would cause too much of a mess.
* cocoa: handle live-resizing differentlywm42015-05-123-42/+41
| | | | | | | | | | | | | | | | | | Instead of requiring a complicated mechanism to share the entire OpenGL and renderer state between VO and Cocoa thread just to do the redrawing during live-resize on the Cocoa thread, let the Cocoa thread wait on the VO thread. This wil allow some major simplifications and cleanups in the future. One problem with this is that it can enter a deadlock whenever the VO tries to sync with the Cocoa thread. To deal with this, the Cocoa thread waits with a timeout. This can probably be improved later, though in general this situation can always happen, unless the Cocoa thread waits in a reentrant way. Some other details aren't completely clean either. For example, pending_events should be accessed atomically. This will also be fixed later.
* vo: use pthread_cond_timedwait() for video timingwm42015-05-121-6/+17
| | | | | | | | | | | | | | | | Will be used to make video waiting interruptible with Cocoa (see the following commit). One worry was that this could cause hangs if the system clock jumps backwards. Normally we don't support such behavior, because it's almost impossible to handle it reasonably. E.g. we would have to change the default clock type for condition variables, which in turn would require a custom function for creating condition variables, or so. If the OS even supports different clocks. But it turns out that this is no issue, because other events seem to wakeup the wait call anyway, and mpv internal absolute times use a monotonic clock.
* vo_opengl_cb: add support for interpolationwm42015-05-121-5/+51
| | | | | | | | | | | | | | | | | This uses the OpenGL frame interpolation code, which before could be used by vo_opengl only. Some effort was made to make it behave like vo_opengl, for the better or the worse. As a consequence, there is a minor duplication of code and mechanism. Hopefully this can all be wiped as soon as the VO frame queue/timing mechanism is cleaned up. This also attempts to use mpv_opengl_cb_report_flip() (as called by the API user) to determine the vsync interval. This might need refinement as well. (In general, we simply expect the API user to work in vsync-blocking manner.)
* vo_opengl_cb: add a "block" framedrop mode and make it defaultwm42015-05-122-7/+31
| | | | | | | | | (I have no idea why there are different modes.) Instead of risking to drop frames too early, give it some margin. Since there are situations this could deadlock, wait with a timeout. This can happen if e.g. the API user is refusing to render anything, or if uninitialization is happening.
* vo_opengl_cb: actually set requested optionswm42015-05-121-0/+1
| | | | Quite an oversight.
* vo: always call draw_image_timed() if availablewm42015-05-121-1/+1
| | | | | | | Gives the VOs more flexibility. gl_video.c already ignores the timing info if no interpolation is active, so this requires no further changes.
* threads: use utility+POSIX functions instead of weird wrapperswm42015-05-119-34/+33
| | | | | | | There is not much of a reason to have these wrappers around. Use POSIX standard functions directly, and use a separate utility function to take care of the timespec calculations. (Course POSIX for using this weird format for time values.)
* ao: make better use of atomicswm42015-05-113-14/+12
| | | | | The main reason for this was compatibility; but some associated problems have been solved in the previous commit.
* atomics: add atomic_fetch_and/atomic_fetch_orwm42015-05-111-7/+20
| | | | | | | | | | As usual, we prefer plain C11 names and semantics, and have to emulate them if C11 atomics are not available. For the non-atomic fallback (which is just there to make code compile in situations the atomic property is not overly important), we require a gross hack to make the generic macros work without using compiler- specific extensions.
* cocoa: remove unused declarationwm42015-05-111-3/+0
|
* cocoa: add missing break statements in switchwm42015-05-111-0/+2
| | | | | The first one (for VOCTRL_GET_DISPLAY_FPS) could have led to undefined behavior if the FPS was unknown. The second is for general symmetry.
* cocoa: remove unused macrowm42015-05-111-1/+0
|
* Always block SIGPIPE globallywm42015-05-114-7/+14
| | | | | | | | | | | | | | | OpenSSL and GnuTLS are still causing this problem (although FFmpeg could be blamed as well - but not really). In particular, it was happening to libmpv users and in cases the pseudo-gui profile is used. This was because all signal handling is in the terminal code, so if terminal is disabled, it won't be set. This was obviously a questionable shortcut. Avoid further problems by always blocking the signal. This is done even for libmpv, despite our policy of not messing with global state. Explicitly document this in the libmpv docs. It turns out that a version bump to 1.17 was forgotten for the addition of MPV_FORMAT_BYTE_ARRAY, so document that change as part of 1.16.
* TOOLS/stats-conv.py: add another event typewm42015-05-111-2/+11
|
* DOCS/man/options.rst: Remove trailing whitespacesrrooij2015-05-101-2/+2
|
* DOCS/man/opions.rst: Elaborate on --no-videorrooij2015-05-101-0/+4
| | | | | When --no-video is set, the ytdl-format is set to "bestaudio/best". This wasn't documented in the man page yet.
* ytdl_hook: remove tabswm42015-05-091-5/+5
| | | | We don't allow tabs in normal source code.
* build: exclude -Wredundant-declswm42015-05-093-5/+4
| | | | | | | It's useless, and creates a bogus warning in subprocess-posix.c. Since I don't know which compilers might have it by default, just change it to -Wno-redundant-decls.
* old-configure: hidewm42015-05-093-4/+1
| | | | It shouldn't be used, but it's still in the repo because I say so.
* old-configure: bump libbluray versionwm42015-05-091-1/+1
| | | | Fixes #1927.
* player: reuse a functionwm42015-05-091-5/+1
| | | | | This has the side-effect that now all encoding-profiles.conf files are loaded. It's not clear if not doing this was intended or not.
* path: improve verbose loggingwm42015-05-091-8/+8
|
* path: use mp_path_join in one more placewm42015-05-091-1/+1
|
* player: make resuming playlists less noisy in verbose modewm42015-05-095-23/+37
| | | | | | | | | | | | | | | | | | | mp_find_config_file() will print the filename lookup and its result in verbose mode. This is wanted, but gets inconvenient when it is done for every playlist entry (for resuming). Lookup the watch_later subdir only once and cache the result instead. This drops the logic for loading the resume file from other locations, which should generally be unnecessary, though might lead to confusion if the user has mixed old and new config paths (which the user shouldn't). Also add a mp_find_user_config_file() function for a more straightforward and reliable way to get actual local configpaths, instead of possibly global and unwritable locations. Also, for symmetry, check the resume option in mp_load_playback_resume() just like mp_check_playlist_resume() does.
* player: avoid undefined behavior when resumign DVD/BD playbackwm42015-05-091-3/+3
| | | | These device options can be NULL, and NULL can't be passed for %s.
* path: make mp_path_join accept normal C stringswm42015-05-0918-28/+34
| | | | | Instead of bstr. Most callers of this function do not need bstr. The bstr version of this function is now mp_path_join_bstr().
* lua: remove deprecated "lua" sub directorieswm42015-05-092-29/+9
| | | | | The compatibility code and the deprecation warning were at least in releases 0.8 and 0.9 - time to get rid of them.
* path: unify the two config file lookup functionswm42015-05-091-83/+60
| | | | | | | | | | | Share most of the implementation of config file lookup between mp_find_all_config_files() and mp_find_config_file(). Also move the check for config path overrides to mp_get_platform_path() directly. From the point of view of config file lookup, this is a bit stupid, but on the other hand increases consistency, as user path resolution exposes the mp_get_platform_path() functionality directly to the user.
* vo_drm: allow changing video rectangle settingswm42015-05-081-0/+6
| | | | | | | | | Now among other things panscan can be changed during playback. Unfortunately, it flickers. The issue is that reconfig() clears the framebuffer. Removing the clearing shows that the "unused" parts of the picture are not cleared - even though OSD could render there. As such, this is a separate issue.
* vo_drm: don't mutate the current frame when clamping for panscanwm42015-05-081-3/+4
| | | | | | When running with --panscan=1, this could crash - because the current frame was reduced in size each time the image was redrawn, which would result in a failed assertion the second time it's drawn.
* input: filter out redundant mp_input_set_mouse_pos() callswm42015-05-081-1/+3
| | | | Prevents the OSC from showing up on start on Cocoa.
* player: add --force-window=immediate modewm42015-05-083-3/+8
| | | | | | | This creates the window before the first file is loaded. This was requested a bunch of times, but on the other hand a change to make this behavior the default was reverted some time ago, because other users hated it.
* audio: simplify furtherwm42015-05-083-28/+11
| | | | | | Drop mp_chmap_diff() (which is unused too now), and implement mp_chmap_diffn() in a slightly simpler way. (Too bad there is no standard function for counting set bits.)
* audio: remove mp_chmap_contains()wm42015-05-083-36/+0
| | | | It's unsued now.
* ao: log reordered versions of channel mapswm42015-05-081-3/+10
| | | | Useful for debugging cases when no standard orders are used.
* audio: redo channel map fallback selectionwm42015-05-082-60/+34
| | | | | | | | | | | | | | | | | | | | Instead of somehow having 4 different cases with each their own weight, do it with a single function that decides which channel layout is the better fallback. This is simpler, and also introduces new (fixed) semantics. The new test added to test/chmap_sel.c actually works now. This is a mixed case with no perfect upmix or downmix, but the better choice is the one which loses the least channels from the original layout. One test also changes. If the input is 7.1(wide-side), and the available layouts are 7.1 and 5.1(side), the latter is now chosen instead of the former. This makes sense: both layouts contain 6 out of 8 channels from the original layout, but the 5.1(side) one is smaller. This follows the general logic. The 7.1 layout has FLC/RLC speakers instead of BL/BR, and judging by the names, "front left center" is completely different from "back left". If these should be exchangeable, a separate exception would have to be added.
* audio: add chmap utility functionwm42015-05-082-0/+10
|
* test: simplify chmap_sel testswm42015-05-081-121/+44
|
* ao_alsa: log requested numbers of channels if ALSA rejects themwm42015-05-081-2/+3
|
* audio: fix messed up assert()wm42015-05-071-1/+1
| | | | This made no sense and always evaluated to true.
* audio: remove UNKNOWN pseudo speakerswm42015-05-073-14/+9
| | | | | | Reuse MP_SPEAKER_ID_NA for this. If all mp_chmap entries are set to NA, the channel layout has special "unknown channel layout" semantics, which are used to deal with some corner cases.
* audio: define only a single NA speaker IDwm42015-05-075-34/+16
| | | | | Remove the requirement from mp_chmap that speaker entries must be unique. Use this to get rid of all the redundant NA speaker IDs.
* player: use profiles for libmpv and encoding defaultswm42015-05-073-24/+34
| | | | | | | | The client API (libmpv) and encoding (--o) have slightly different defaults from the command line player. Instead of doing a bunch of calls to set the options explicitly, use profiles. This is simpler and has the advantage that they can be listed on command line (instead of possibly forcing the user to find and read the code to know all the details).
* m_config: make m_config_set_profile() use a namewm42015-05-073-13/+18
| | | | Is simpler and avoids exposing profile structs to a degree.
* DOCS: add a link to LIRC wiki entrywm42015-05-071-0/+1
|
* ao_coreaudio_utils: don't list some formats as "unusable"wm42015-05-071-1/+1
| | | | | While mpv has no internal equivalent representation, they can still be used as physical CoreAudio formats. Thus this label is confusing.
* ytdl_hook: Escape EDL URLsChrisK22015-05-071-1/+3
| | | | | Should prevent the EDL parser from tripping over = and , in the URL.
* ao_sndio: add notice about padding channelswm42015-05-061-1/+3
| | | | (I won't do this, but someone else seeing this might.)
* ao_alsa: use new padding channels supportwm42015-05-061-21/+26
| | | | | | | | | | | | Sometimes, ALSA will return channel layouts with padded channels (NA speakers). Use them instead of failing. This still includes the old "braindeath" code to retry with a layout without NA channels. This might be helpful for performance, and also the padded channel layout string looks confusing. To be fair, I have not encountered a case yet which would really need this, and for which the old "braindeath" code did not fix it.
* ao_alsa: move ALSA -> mp channel map to a functionwm42015-05-061-11/+18
| | | | | One side effect is that the warning about too many channels goes away, and is replaced with printing the ALSA channel map as "unknown".
* manpage: do not use deprecated syntax in examplewm42015-05-061-1/+1
|
* cocoa: remove an unused parameterwm42015-05-063-3/+3
|
* ao_coreaudio_exclusive: check new format before waiting for changewm42015-05-061-12/+13
| | | | | It seems if the format was already set, setting the same format will not cause a property change.
* ao_coreaudio_exclusive: use atomics instead of volatilewm42015-05-061-19/+16
| | | | | | | | | | | volatile barely means anything. The polling is kind of bad too, but relatively harmless as device opening/closing is a rare event, and the format change is not expected to take long. Remove the pointless talloc call too (must have been a leftover from previous refactoring).
* ao_coreaudio_exclusive: rename "digital" -> "compressed"wm42015-05-061-22/+20
| | | | PCM is digital too.
* ao_coreaudio_exclusive: explicitly check for spdif formatswm42015-05-061-8/+5
|
* ao_coreaudio_exclusive: merge init_digital() functionwm42015-05-061-15/+3
| | | | | | No reason to keep them separate. It's an artifact from the old ao_coreaudio.c, which kept usage of two different APIs in the same file. Removes a forward reference too.
* cocoa: lock cocoa main thread on uninitwm42015-05-061-1/+9
| | | | | | | | | | | | | | | | | | This should fix some crashes due to dangling pointers. The problem was that with_cocoa_lock_on_main_thread() is asynchronous. It will not wait until it is finished. In the uninit case, this means the VO could be deallocated and destroyed while cocoa was still running uninit code. So simply wait until it is done by using dispatch_sync(). There were concerns that this could introduce a deadlock by the main thread trying to wait for something on the VO thread. But from what I can see, this never happens, and even if it does, it would crash anyway since the VO is already gone. One remaining worry is the video_resize_redraw_callback. From what I can see, it still can mess things up, and will need a more elaborate fix.
* ao_coreaudio_utils: decide formats by comparing raw bitswm42015-05-051-5/+6
| | | | | | | | | | | | | | | | Instead of trying to use af_format_conversion_score() (which tries to be all kinds of clever), just compare the raw bits as a quality measure. Do this because otherwise, weird formats like padded 24 bit formats will be excluded, even though they might be the highest precision formats for some hardware. This means that for now, the user would have to check whether the format is usable at all before calling ca_asbd_is_better(). But since this is currently only used for ao_coreaudio.c and for the physical format, it doesn't matter. If coreaudio-exclusive should get PCM support, the best would be to revert this change, and to add support for 24 bit formats directly.
* ao_coreaudio: log considered