summaryrefslogtreecommitdiffstats
path: root/player
Commit message (Collapse)AuthorAgeFilesLines
* js: use new hooks API (match f60826c3)Avi Halachmi (:avih)2018-04-072-10/+50
|
* js: dump(..): fix incorrect <VISITED> with array argumentAvi Halachmi (:avih)2018-04-071-1/+1
| | | | | | | | | | | | | | | | | | | | | When dump's argument is an array, it was displaying <VISITED> for all the array's object elements (objects, arrays, etc), regardless if they're actually visited or not. The reason is that we try to stringify twice: once normally which may throw (on cycles), and a second time while excluding visited items which is indicated by binding the replacer to an empty array - in which we hold the visited items, where the replacer tests if its 'this' is an array or not and acts accordingly. However, its "this" may also be an array even if we don't bind it to one, because its "normal" this is the main stringified object, so the test of Array.isArray(this) is true when the top object is an array, and the object items are indeed are in it - so the replacer considers them visited. Fix by binding to null on the first attempt such that "this" is an array only when we want it to test for visited items and not when the argument itself is an array.
* js: implement mp.register_idleAvi Halachmi (:avih)2018-04-071-2/+37
| | | | | | | | | | Due to earlier misinterpretation of the Lua docs as if mp.register_idle registers a one-shot callback, the JS docs suggested to use setTimeout. But the behavior and Lua docs are such that it's a repeating callback which fires just before the script thread goes to sleep. Implement it for JS too.
* js: implement mp.options.read_optionsAvi Halachmi (:avih)2018-04-071-0/+52
|
* config: replace config dir lua-settings/ with dir script-opts/Avi Halachmi (:avih)2018-04-071-1/+9
| | | | lua-settings/ is still supported, with deprecation warning.
* player: fix hook processing consistency and code duplication issueswm42018-03-263-45/+20
| | | | | | | | | | | | | | | | | | | | | | | | There was a "generic" function to run a hook and to wait for its completion, yet there were two duplicated functions doing the same anyway. Replace them with a single function. They differed in how stop_play was handled, but it was broken anyway. stop_play is set when playback is stopped due to quitting or changing the playlist entry - but we still can't stop hook processing, because that would mean asynchronously doing something else while the user hook code is still busy and might still have the expectation that running the hook stops everything else. So not waiting until the hook ends properly is against the whole hook idea. That this was done inconsistently is even worse. (Though it could be argued that when quitting the player, everything should just be stopped violently. But I still think that's up to the hook handler.) process_hooks() does not return anything, since hook processing doesn't really have a result (it's all about blocking and letting some other code synchronously do something). Just let the caller check whether loading was aborted in the meantime. Also change the potentially misleading name of mp_hook_run().
* client API: add a first class hook API, and deprecate old APIwm42018-03-268-67/+154
| | | | | | | | | | | | | | | As it turns out, there are multiple libmpv users who saw a need to use the hook API. The API is kind of shitty and was never meant to be actually public (it was mostly a hack for the ytdl script). Introduce a proper API and deprecate the old one. The old one will probably continue to work for a few releases, but will be removed eventually. There are some slight changes to the old API, but if a user followed the manual properly, it won't break. Mostly untested. Appears to work with ytdl_hook.
* command: remove an old compatibility hackwm42018-03-261-48/+1
| | | | | Was removed 3 releases ago and was spamming warning messages that it'll be dropped, so it's fine to remove it now.
* command: remove duplication of property set error message handlingwm42018-03-261-59/+36
| | | | | | | | Move all of this stuff to a common function. This makes the error messages less specific, but I don't think anyone will miss it. The OSD flag handling is annoying, but it's nothing that should be changed with this commit.
* command: move property multiply code to m_property.cwm42018-03-261-26/+3
| | | | | | | I think this will help with reducing code duplication (see following commit). The error messages loses the multiplication factor, but the error message will be replaced by a generic one in the following commit anyway.
* command: use mpv_node helpers instead of duplicated codewm42018-03-261-26/+8
| | | | | | They didn't exist yet when this code was added. Completely untested.
* client API: add a new way to pass X11 Display etc. to render APIwm42018-03-261-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Hardware decoding things often need access to additional handles from the windowing system, such as the X11 or Wayland display when using vaapi. The opengl-cb had nothing dedicated for this, and used the weird GL_MP_MPGetNativeDisplay GL extension (which was mpv specific and not officially registered with OpenGL). This was awkward, and a pain due to having to emulate GL context behavior (like needing a TLS variable to store context for the pseudo GL extension function). In addition (and not inherently due to this), we could pass only one resource from mpv builtin context backends to hwdecs. It was also all GL specific. Replace this with a newer mechanism. It works for all RA backends, not just GL. the API user can explicitly pass the objects at init time via mpv_render_context_create(). Multiple resources are naturally possible. The API uses MPV_RENDER_PARAM_* defines, but internally we use strings. This is done for 2 reasons: 1. trying to leave libmpv and internal mechanisms decoupled, 2. not having to add public API for some of the internal resource types (especially D3D/GL interop stuff). To remain sane, drop support for obscure half-working opengl-cb things, like the DRM interop (was missing necessary things), the RPI window thing (nobody used it), and obscure D3D interop things (not needed with ANGLE, others were undocumented). In order not to break ABI and the C API, we don't remove the associated structs from opengl_cb.h. The parts which are still needed (in particular DRM interop) needs to be ported to the render API.
* player: don't print error if aborted while loading external fileswm42018-03-261-1/+2
|
* stats: print section titles independentlyJulian2018-03-251-3/+6
| | | | | | | Previously, section titles (File/Video/Audio) were printed as suffix of a property that was assumed to always exist. However, with e.g. lavi-complex this is not the case, therfore, print them without being dependent on a property.
* stats: improve video/audio detectionJulian2018-03-251-30/+29
| | | | | | | | | Switch from audio|video to audio|video-out-params properties as per recommendation in #5670. These properties are tables and include information explicitly queried later, so switch to using these tables and reduce the amount of queried properties. Fixes #5670
* vo: pass through framedrop flag differentlywm42018-03-152-12/+2
| | | | | | | | There is some sort-of awkwardness here, because option access needs to happen in a synchronized manner, and the framedrop flag is not in the VO option struct. Remove the mp_read_option_raw() call and the awkward change notification via VO_EVENT_WIN_STATE from command.c, and pass it through as new vo_frame flag.
* vo: move display-fps internal option value to VO optswm42018-03-151-11/+4
| | | | | | Removes the awkward notification through VO_EVENT_WIN_STATE. Unfortunately, some awkwardness remains in mp_property_display_fps(), because the property has conflicting semantics with the option.
* client API: send MPV_EVENT_SHUTDOWN only oncewm42018-03-151-0/+2
| | | | | | | | | | | | Before this change, mpv_wait_event() could inconsistently return multiple MPV_EVENT_SHUTDOWN events to a single mpv_handle, up to the point of spamming the event queue under certain circumstances. Change this and just send it exactly once to each mpv_handle. Some client API users might have weird requirements about destroying their state asynchronously (and not reacting immediately to the SHUTDOWN event). This change will help a bit to make this less weird and surprising.
* all: replace mpv_detach_destroy() with mpv_destroy()wm42018-03-151-2/+2
|
* client API: rename mpv_detach_destroy() to mpv_destroy()wm42018-03-151-1/+6
| | | | | Since this has clearer semantics now, the old name is just clunky and confusing.
* client API: add mpv_create_weak_client()wm42018-03-153-2/+23
|
* client API: cleanup mpv_handle terminationwm42018-03-154-106/+121
| | | | | | | | | | | | | | | This changes how mpv_terminate_destroy() and mpv_detach_destroy() behave. The doxygen in client.h tries to point out the differences. The goal is to make this more useful to the API user (making it behave like refcounting). This will be refined in follow up commits. Initialization is unfortunately closely tied to termination, so that changes as well. This also removes earlier hacks that make sure that some parts of FFmpeg initialization are run in the playback thread (instead of the user's thread). This does not matter with standard FFmpeg, and I have no reason to care about this anymore.
* player: move locale check to mp_create()wm42018-03-152-25/+30
| | | | | | The intention is to reduce annoying differences between mpv CLI and libmpv, and there's no reason to have the locale check only in libmpv (although it doesn't help with any real issues either).
* player: shuffle around CLI exit code handlingwm42018-03-152-58/+44
| | | | | Remove the weird prepare_exit_cplayer() function, and fold the contents into mpv_main() and mp_initialize().
* scripting: make a function staticwm42018-03-082-2/+1
|
* client: remove legacy API that is unused nowAkemi2018-03-042-44/+1
| | | | | | this API was introduced in c5e4538 solely for the use with cocoa-cb and was not public. with the port to the new API in 760d471 it is now unused and can safely be removed.
* player: fix strange behavior on edition switchingwm42018-03-031-0/+2
| | | | | | | After switching, the playback state was not reset, which could leave it in a strange, pause like state, that could be fixed by e.g. seeking. This seems to be an older regression - it's even in 0.27.
* player: don't free root filter while it's still neededwm42018-03-031-1/+1
| | | | | | | | | | | | | | Sometimes, playback needs to be fully uninitialized and reinitialized without "officially" closing and reopening the playlist entry. This happens with PT_RELOAD_FILE, which is triggered by edition switching and also DVD/BD title switching. (Not really sure why it goes through so much pain for such obscure cases. All it gains is not resetting "local" options, and not signaling a reload to the client API. Whatever.) The recent filter change freed filter_root too early without recreating it, so it crashed on edition switching. Fixes #5587.
* player: fix track autoselection of external files yet againwm42018-03-031-3/+3
| | | | | | If you used --aufio-file=file.mkv, and file.mkv included a video track marked as default, then the logic in select_default_track() would pick the video track from file.mkv. This is 100% broken, so fix it.
* command: fix whitespacewm42018-03-031-1/+1
|
* video: add option to reduce latency by 1 or 2 frameswm42018-03-031-4/+8
| | | | | | | | | | | | | | | | | | | | The playback start logic explicitly waits until the first frame has been displayed. Usually this will introduce a wait of 1 vsync. For normal playback this doesn't matter, but with respect to low latency needs, this only leads to additional data getting queued up in the demuxer or network buffers. Another thing is that the timing logic decodes 1 frame ahead (= 1 frame extra latency) to determine the exact duration of a frame. To be fair, there doesn't really seem to be a hard reason why this is needed. With the current code, enabling the option does lead to A/V desync sometimes (if the demuxer FPS is too inaccurate), and also frame drops at playback start in some situations. But this all seems to be avoidable, if the timing logic were to be rewritten completely, which should probably happen in the future. Thus the new option comes with the warning that it can be removed any time. This is also why the option has "hack" in the name.
* video: don't read ahead a frame in --untimed modewm42018-03-031-0/+3
| | | | | The extra frame is used to compute the exact frame duration. But frame drop is disabvled with --untimed.
* player: set thread name in opener threadwm42018-03-031-0/+3
| | | | Somewhat helpful for debugging.
* player: add warning comment about ignoring ABI safetywm42018-03-031-0/+3
| | | | | At least ffmpeg_garbage() uses sizeof(AVFrameSideData), which is not included in the ABI, but there's no ABI-safe alternative either.
* client API: deprecate opengl-cb API and introduce a replacement APIwm42018-02-286-35/+155
| | | | | | | | | | | | | | | | | | | | | | | | | The purpose of the new API is to make it useable with other APIs than OpenGL, especially D3D11 and vulkan. In theory it's now possible to support other vo_gpu backends, as well as backends that don't use the vo_gpu code at all. This also aims to get rid of the dumb mpv_get_sub_api() function. The life cycle of the new mpv_render_context is a bit different from mpv_opengl_cb_context, and you explicitly create/destroy the new context, instead of calling init/uninit on an object returned by mpv_get_sub_api(). In other to make the render API generic, it's annoyingly EGL style, and requires you to pass in API-specific objects to generic functions. This is to avoid explicit objects like the internal ra API has, because that sounds more complicated and annoying for an API that's supposed to never change. The opengl_cb API will continue to exist for a bit longer, but internally there are already a few tradeoffs, like reduced thread-safety. Mostly untested. Seems to work fine with mpc-qt.
* audio: improve behavior if filters output nothing during probingwm42018-02-211-0/+5
| | | | | | | | | | Just bail out immediately (and disable audio) if format probing has no result, instead of doing nothing and then apparently freezing. This can happen with bogus filters, cases where the first audio frame is essentially dropped by filters (can happen with large resampling factors), and if the audio track contains no packets at all, or all packets fail to decode.
* video: do not buffer extra frames with VO_CAP_NORETAIN outputsAman Gupta2018-02-171-0/+3
| | | | | | | | | | | | | | This fixes playback stalls on some mediacodec hardware decoders, which expect that frame buffers will be rendered and returned back to the decoder as soon as possible. Specifically, the issue was observed on an NVidia SHIELD Android TV, only when playing an H264 sample which switched between interlaced and non-interlaced frames. On an interlacing change, the decoder expects all outstanding frames would be returned to it before it would emit any new frames. Since a single extra frame always remained buffered by mpv, playback would stall. After this commit, no extra frames are buffered by mpv when using vo_mediacodec_embed.
* command: simplify mp_property_filter_metadatawm42018-02-161-19/+11
| | | | Also silence a dead code coverity error.
* lua+js: Implement utils.getpid()sfan52018-02-132-0/+16
| | | | | | | Usable for uniquely identifying mpv instances from subprocesses, controlling mpv with AppleScript, ... Adds a new mp_getpid() wrapper for cross-platform reasons.
* input: add a keybinding to toggle hardware decodingwm42018-02-131-0/+1
| | | | | We sure as hell won't enable hardware decoding by default, but we can make it more accessible with a key binding.
* audio: move back PTS jump detection to before filter chainwm42018-02-132-20/+4
| | | | | | | | | | | The recent changes to player/audio.c moved PTS jump detection to after audio filtering. This was mostly done for convenience, because dataflow between decoder and filters was made "automatic", and jump detection would have to be done as filter. Now move it back to after decoders, again out of convenience. The future direction is to make the dataflow between filters and AO automatic, so this is a bit in the way. Another reason is that speed changes tend to cause jumps - these are legitimate, but get annoying quickly.
* cocoa-cb: initial implementation via opengl-cb APIAkemi2018-02-122-3/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | this is meant to replace the old and not properly working vo_gpu/opengl cocoa backend in the future. the problems are various shortcomings of Apple's opengl implementation and buggy behaviour in certain circumstances that couldn't be properly worked around. there are also certain regressions on newer macOS versions from 10.11 onwards. - awful opengl performance with a none layer backed context - huge amount of dropped frames with an early context flush - flickering of system elements like the dock or volume indicator - double buffering not properly working with a none layer backed context - bad performance in fullscreen because of system optimisations all the problems were caused by using a normal opengl context, that seems somewhat abandoned by apple, and are fixed by using a layer backed opengl context instead. problems that couldn't be fixed could be properly worked around. this has all features our old backend has sans the wid embedding, the possibility to disable the automatic GPU switching and taking screenshots of the window content. the first was deemed unnecessary by me for now, since i just use the libmpv API that others can use anyway. second is technically not possible atm because we have to pre-allocate our opengl context at a time the config isn't read yet, so we can't get the needed property. third one is a bit tricky because of deadlocking and it needed to be in sync, hopefully i can work around that in the future. this also has at least one additional feature or eye-candy. a properly working fullscreen animation with the native fs. also since this is a direct port of the old backend of the parts that could be used, though with adaptions and improvements, this looks a lot cleaner and easier to understand. some credit goes to @pigoz for the initial swift build support which i could improve upon. Fixes: #5478, #5393, #5152, #5151, #4615, #4476, #3978, #3746, #3739, #2392, #2217
* ytdl_hook: add ytdl:// prefix again for non-youtube playlistsRicardo Constantino2018-02-111-2/+6
| | | | | | | | Only youtube playlists return ID-only urls. Other extractors may return "<extractor>:<ID>" so those still need the ytdl:// prefix. Reproduced with http://www.cbc.ca/burdenoftruth/videos/trailers-promos/burden-of-truth-returns
* ytdl_hook: add script opt for using manifest URLsRicardo Constantino2018-02-111-2/+3
| | | | | | | | | | | Disable by default. This feature was added in 7eb342757, which allowed stream selection in runtime. Problem with this atm is that FFmpeg will try to demux every first packet of every track leading to noticeable delay opening the URL. This option can be changed to enabled by default or removed when HLS/DASH demuxers are improved upstream.
* ytdl_hook: parse youtube playlist urls to set start indexRicardo Constantino2018-02-111-5/+53
| | | | | | | | | | | | | | Still needs `--ytdl-raw-option=yes-playlist=` because this only works for youtube. This was requested in a few issues: https://github.com/mpv-player/mpv/issues/1400 https://github.com/mpv-player/mpv/issues/2592 https://github.com/mpv-player/mpv/issues/3024 For #1400 to be completely implemented would need ytdl_hook to re-request the same playlist with the last video's ID for the mix to continue indefinitely which would probably too hackish to work reliably.
* ytdl_hook: exit early, save an indentation levelRicardo Constantino2018-02-111-164/+165
|
* ytdl_hook: various nitRicardo Constantino2018-02-111-9/+5
| | | | | | | | Remove obsolete comment about FFmpeg ignoring non-http proxies which was repeated in ytdl_hook before the feature was added. Remove unnecessary conditions for not nil. Lua tables will always return nil for non-existent keys.
* ytdl_hook: whitelist subtitle URLs as wellRicardo Constantino2018-02-111-2/+4
| | | | | This was overlooked when doing the whitelisting for video and audio to fix #5456.
* ytdl_hook: use fallback if there's no demuxer-lavf-list propRicardo Constantino2018-02-111-3/+3
| | | | | | | This is important if backporting by grabbing the latest version of the script without backporting the commit that added the property: 828bd2963cd10a851e0a977809687aed4d377dc3
* vo_gpu: make screenshots use the GL rendererwm42018-02-111-7/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | Using the GL renderer for color conversion will make sure screenshots will use the same conversion as normal video rendering. It can do this for all types of screenshots. The logic when to write 16 bit PNGs changes. To approximate the old behavior, we decide by looking whether the source video format has more than 8 bits per component. We apply this logic even for window screenshots. Also, 16 bit PNGs now always include an unused alpha channel. The reason is that FFmpeg has RGB48 and RGBA64 formats, but no RGB064. RGB48 is 3 bytes and usually not supported by GPUs for rendering, so we have to use RGBA64, which forces an alpha channel. Will break for users who use --target-trc and similar options. I considered creating a new gl_video context, but it could double GPU memory use, so I didn't. This uses FBOs instead of glGetTexImage(), because that increases the chance it could work on GLES (e.g. ANGLE). Untested. No support for the Vulkan and D3D11 backends yet. Fixes #5498. Also fixes #5240, because the code for reading back is not used with the new code path.
* player: correctly set track information on adding external filesZehua Chen2018-02-103-34/+44
| | | | | | | | Before this commit, auto_loaded and lang were only set for the first track in auto-loaded external files. Likewise, for the title and lang arguments to the sub-add and audio-add commands. Fixes #5432
* loadfile: make --lavfi-complex runtime changes more flexiblewm42018-02-031-18/+27
| | | | | | | | | Setting lavfi-complex at runtime will now forcefully reselect the tracks as needed, even if it was a "proper" track selection via --aid or --vid. Before this commit, it just failed and complained that the VO/AO was already "used". Requested.
* loadfile: initialize decoders after outputs for --lavfi-complexwm42018-02-031-37/+31
| | | | | | | This makes it actually somewhat simpler, and doesn't have any disadvantages. It should also make some new features easier. Mostly just moves code around.
* loadfile: fix crash in some cases of setting --lavfi-complex at runtimewm42018-02-031-1/+1
| | | | | | | | | The somewhat confus