summaryrefslogtreecommitdiffstats
path: root/player
Commit message (Collapse)AuthorAgeFilesLines
* command: change cycle-value command behaviorwm42018-04-291-73/+88
| | | | | | | | | | | | | | | | | | | | Instead of using an internal counter to keep track of the value that was set last, attempt to find the current value of the property/option in the value list, and then set the next value in the list. There are some potential problems. If a property refuses to accept a specific value, the cycle-values command will fail, and start from the same position again. It can't know that it's supposed to skip the next value. The same can happen to properties which behave "strangely", such as the "aspect" property, which will return the current aspect if you write "-1" to it. As a consequence, cycle-values can appear to get "stuck". I still think the new behavior is what users expect more, and which is generally more useful. We won't restore the ability to get the old behavior, unless we decide to revert this commit entirely. Fixes #5772, and hopefully other complaints.
* command: make track properties cycle through no/auto if uninitializedwm42018-04-291-9/+18
| | | | | | | | | | | | | If playback has not been initialized yet (decoders not initialized etc.), or if in idle mode, let the track properties cycle through "no" and "auto". This should be slightly more helpful than making it simply exit. Depending on the stage of loading, more could be done. For example, if youtube-dl loads additional subtitle files, it can happen that these get added before the main file, and this could be cycled through to an extent. This is probably too clever, and also sort of dangerous (unintended interactions with messy in-loading state), so don't do it.
* command: fix coding stylewm42018-04-291-5/+6
| | | | Add {...}, change if(!a) to if(a) and swap its if/else body.
* player: don't wait for last video frame in encode modewm42018-04-291-0/+3
| | | | | This code makes the player wait using real time, which makes sense for normal playback, but not encode mode.
* encode: rewrite half of itwm42018-04-293-13/+19
| | | | | | | | | | | | | The main change is that we wait with opening the muxer ("writing headers") until we have data from all streams. This fixes race conditions at init due to broken assumptions in the old code. This also changes a lot of other stuff. I found and fixed a few API violations (often things for which better mechanisms were invented, and the old ones are not valid anymore). I try to get away from the public mutex and shared fields in encode_lavc_context. For now it's still needed for some timestamp-related fields, but most are gone. It also removes some bad code duplication between audio and video paths.
* vo: add vo_reconfig2()wm42018-04-291-1/+1
| | | | | | 1. I want to get away from mp_image_params (maybe). 2. For encoding mode, it's convenient to get the nominal_fps, which is a mp_image field, and not in mp_image_params.
* encode: some more cleanupswm42018-04-291-1/+0
|
* video: remove internal stereo_out flagwm42018-04-291-3/+1
| | | | | | Also rename stereo3d to stereo_in. The only real change is that the vo_gpu OSD code now uses the actual stereo 3D mode, instead of the --video-steroe-mode value. (Why does this vo_gpu code even exist?)
* client API: preparations for allowing render API to use DR etc.wm42018-04-292-6/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | DR (letting the decoder allocate texture memory) requires running the allocation on the render thread. This is rather hard with the render API, because the user controls this thread and when it's entered. It was not possible until now. This commit adds a bunch of infrastructure to make this possible. We add a new optional mode (MPV_RENDER_PARAM_ADVANCED_CONTROL) which basically lets the user's render thread and libmpv agree how this should be done. Misuse would lead to deadlocks. To make this less likely, strictly document thread safety/locking issues. In particular, document which libmpv functions can be called without issues. (The rest has to be assumed unsafe.) The worst issue is destruction of the render context while video is still active. To avoid certain unintended recursive locks (i.e. deadlocks, unless we'd make the locks recursive), make the update callback lock separate. Make "killing" the video chain asynchronous, so we can do extra work while video is being destroyed. Because losing wakeups is a big deal, setting the update callback now triggers a wakeup. (It would have been better if the wakeup callback were a parameter to mpv_render_context_create(), but too late.) This commit does not add DR yet; the following commit does this.
* audio: fix EOF handling if there was no data at allwm42018-04-201-0/+7
| | | | | | It stopped and did nothing, instead of terminating (or just letting video play, if there was any video). Regression due to recent filter changes.
* player: remove in_dispatch fieldwm42018-04-182-9/+5
| | | | (Not sure if worth the trouble, but it does seem less awkward.)
* scripting: change when/how player waits for scripts being loadedwm42018-04-182-20/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fundamentally, scripts are loaded asynchronously, but as a feature, there was code to wait until a script is loaded (for a certain arbitrary definition of "loaded"). This was done in scripting.c with the wait_loaded() function. This called mp_idle(), and since there are commands to load/unload scripts, it meant the player core loop could be entered recursively. I think this is a major complication and has some problems. For example, if you had a script that does 'os.execute("sleep inf")', then every time you ran a command to load an instance of the script would add a new stack frame of mp_idle(). This would lead to some sort of reentrancy horror that is hard to debug. Also misc/dispatch.c contains a somewhat tricky mess to support such recursive invocations. There were also some bugs due to this and due to unforeseen interactions with other messes. This scripting stuff was the only thing making use of that reentrancy, and future commands that have "logical" waiting for something should be implemented differently. So get rid of it. Change the code to wait only in the player initialization phase: the only place where it really has to wait is before playback is started, because scripts might want to set options or hooks that interact with playback initialization. Unloading of builtin scripts (can happen with e.g. "set osc no") is left asynchronous; the unloading wasn't too robust anyway, and this change won't make a difference if someone is trying to break it intentionally. Note that this is not in mp_initialize(), because mpv_initialize() uses this by locking the core, which would have the same problem. In the future, commands which logically wait should use different mechanisms. Originally I thought the current approach (that is removed with this commit) should be used, but it's too much of a mess and can't even be used in some cases. Examples are: - "loadfile" should be made blocking (needs to run the normal player code and manually unblock the thread issuing the command) - "add-sub" should not freeze the player until the URL is opened (needs to run opening on a separate thread) Possibly the current scripting behavior could be restored once new mechanisms exist, and if it turns out that anyone needs it. With this commit there should be no further instances of recursive playloop invocations (other than the case in the following commit), since all mp_idle()/mp_wait_events() calls are done strictly from the main thread (and not commands/properties or libmpv client API that "lock" the main thread).
* demux, player: mark dependent tracksAman Gupta2018-04-172-1/+2
| | | | | | | ffmpeg marks audio tracks which are not meant to be played standalone as DEPENDENT. these are typically used in DVB broadcasts for audio descriptions, and are meant to be mixed into the main audio track during playback.
* client API: make sure to send IDLE event after mpv_initialize()wm42018-04-161-0/+1
| | | | | | | | | | | This was slightly broken: since mp_initialize() did not necessarily interrupt core_thread() (which is waiting for initialization), it did not enter mp_play_files(), which would have sent an IDLE event. I suppose that in some cases (like with mpv-android), the initial IDLE event was never actually sent, because the first wakeup of the core thread happens with the "loadfile" command, which will disallow the core thread an IDLE event.
* client API: fix potential sporadic freezes on terminationwm42018-04-161-4/+4
| | | | | | | | | | | | | | | Although this was never observed to be happening, it seems definitely possible: we first tell the main thread to exit, and then we ask the main thread to do some work for us (with mp_dispatch_run()). Obviously this is racy, and the main thread could exit without doing this, which would block mp_dispatch_run() forever. Fix this by changing the order of operation, so that it makes sense. We could also just store the pthread_t of the main thread in some variable, but the fact that pthread_create() might set the pthread_t argument _after_ starting the thread makes this a bit messy (at least it doesn't seem to be guaranteed on a superficial look at the manpage).
* audio: don't recreate AO if a filter changes the output formatwm42018-04-151-1/+28
| | | | | | | | | | | | | | | | | | | | | | | Until recently, the AO was reinitialized strictly only on decoder format changes. But the commit for simplifying audio format negotiation removed this. Now the AO is recreated for any format change. This is sort of annoying if you change playback speed. The insertion/removal of af_scaletempo can change the sample format. For example, the acompressor filter will convert output to double, so toggling scaletempo will force the format back to float. This recreates the AO under the --gapless-audio=weak default. This likely affects a lot of other filters too. Work this around by allowing sample format changes, and keeping the current AO format in these cases. This is probably not a big problem. Most audio APIs force the output format to float anyway. This means you actually have to worry about what the default gapless mode does to your audio. If you start with a file that uses 8 bit per sample, and then continue playing a 24 bit FLAC, it will be converted down to 8 bit per sample. (Assuming they are played in a way that uses the gapless logic.)
* ytdl_hook: don't log error when loading is abortedwm42018-04-151-2/+6
|
* 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