summaryrefslogtreecommitdiffstats
path: root/player/core.h
Commit message (Collapse)AuthorAgeFilesLines
* player: change the role of the "stop_play" and "playing" variablewm42018-05-241-2/+3
| | | | | | | | | | | | | | | | | Before this, mpctx->playing was often used to determine whether certain new state could be added to the playback state. In particular this affected external files (which added tracks and demuxers). The variable was checked to prevent that they were added before the corresponding uninit code. We want to make a small part of uninit asynchronous, but mpctx->playing needs to stay in the place where it is. It can't be used for this purpose anymore. Use mpctx->stop_play instead. Make it never have the value 0 outside of loading/playback. On unloading, it obviously has to be non-0. Change some other code in playloop.c to use this, because it seems slightly more correct. But mostly this is preparation for the following commit.
* player: simplify edition switchingwm42018-05-241-1/+0
| | | | | | | | | | | | | | The player fully restarts playback when the edition or disk title is changed. Before this, the player tried to reinitialized playback partially. For example, it did not print a new "Playing: <file>" message, and did not send playback end to libmpv users (scripts or applications). This playback restart code was a bit messy and could have unforeseen interactions with various state. There have been bugs before. Since it's a mostly cosmetic thing for an obscure feature, just change it to a full restart. This works well, though since it may have consequences for scripts or client API users, mention it in interface-changes.rst.
* player: make various commands for managing external tracks abortablewm42018-05-241-3/+2
| | | | | | | | | | | | | | | | | | | | | Until now, they could be aborted only by ending playback, and calling mpv_abort_async_command didn't do anything. This requires furthering the mess how playback abort is done. The main reason why mp_cancel exists at all is to avoid that a "frozen" demuxer (blocked on network I/O or whatever) cannot freeze the core. The core should always get its way. Previously, there was a single mp_cancel handle, that could be signaled, and all demuxers would unfreeze. With external files, we might want to abort loading of a certain external file, which automatically means they need a separate mp_cancel. So give every demuxer its own mp_cancel, and "slave" it to whatever parent mp_cancel handles aborting. Since the mpv demuxer API conflates creating the demuxer and reading the file headers, mp_cancel strictly need to be created before the demuxer is created (or we couldn't abort loading). Although we give every demuxer its own mp_cancel (as "enforced" by cancel_and_free_demuxer), it's still rather messy to create/destroy it along with the demuxer.
* client API: kill async commands on terminationwm42018-05-241-0/+1
| | | | | | | | | | | This affects async commands started by client API, commands with async capability run in a sync way by client API (think mpv_command_node() with "subprocess"), and detached async work. Since scripts might want to do some cleanup work (that might involve launching processes, don't ask), we don't unconditionally kill everything on exit, but apply an arbitrary timeout of 2 seconds until async commands are aborted.
* command: add a way to abort asynchronous commandswm42018-05-241-0/+22
| | | | | | | | | | | | Many asynchronous commands are potentially long running operations, such as loading something from network or running a foreign process. Obviously it shouldn't just be possible for them to freeze the player if they don't terminate as expected. Also, there will be situations where you want to explicitly stop some of those operations explicitly. So add an infrastructure for this. Commands have to support this explicitly. The next commit uses this to actually add support to a command.
* player: rename "lock" to "abort_lock"wm42018-05-241-2/+2
| | | | | | If a struct as large as MPContext contains a field named "lock", it creates the impression that it is the primary lock for MPContext. This is wrong, the lock just protects a single field.
* player: make all external file loading actions asyncwm42018-05-241-1/+3
| | | | | Still missing: not freezing when removing a track (i.e. closing demuxer) with the sub-remove/audio-remove/rescan-external-files commands.
* command: make sub-add and audio-add commands asyncwm42018-05-241-1/+1
| | | | | | | | | | Pretty trivial, since commands can be async now, and the common code even provides convenience like running commands on a worker thread. The only ugly thing is that mp_add_external_file() needs an extra flag for locking. This is because there's still some code which calls this synchronously from the main thread, and unlocking the core makes no sense there.
* command: add infrastructure for async commandswm42018-05-241-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | This enables two types of command behavior: 1. Plain async behavior, like "loadfile" not completing until the file is fully loaded. 2. Running parts of the command on worker threads, e.g. for I/O, such as "sub-add" doing network accesses on a thread while the core continues. Both have no implementation yet, and most new code is actually inactive. The plan is to implement a number of useful cases in the following commits. The most tricky part is handling internal keybindings (input.conf) and the multi-command feature (concatenating commands with ";"). It requires a bunch of roundabout code to make it do the expected thing in combination with async commands. There is the question how commands should be handled that come in at a higher rate than what can be handled by the core. Currently, it will simply queue up input.conf commands as long as memory lasts. The client API is limited by the size of the reply queue per client. For commands which require a worker thread, the thread pool is limited to 30 threads, and then will queue up work in memory. The number is completely arbitrary.
* demux, player: fix playback of sparse video streams (w/ still images)Aman Gupta2018-05-241-0/+2
| | | | | | | | | | | | | | | Fixes several issues playing back mpegts with video streams marked as having "still images". For example, see this video which has frames only every 6s: https://s3.amazonaws.com/tmm1/music-choice.ts Changes include: - start playback right away, without waiting for first video frame - do not consider the sparse video stream in demuxer underrun detection - do not require multiple video frames for the VO - use audio as the master stream for demuxer metadata events - use audio stream for playback time Signed-off-by: Aman Gupta <aman@tmm1.net>
* player: remove in_dispatch fieldwm42018-04-181-1/+0
| | | | (Not sure if worth the trouble, but it does seem less awkward.)
* demux, player: mark dependent tracksAman Gupta2018-04-171-1/+1
| | | | | | | 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: cleanup mpv_handle terminationwm42018-03-151-1/+1
| | | | | | | | | | | | | | | 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.
* scripting: make a function staticwm42018-03-081-1/+0
|
* client API: deprecate opengl-cb API and introduce a replacement APIwm42018-02-281-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | 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: move back PTS jump detection to before filter chainwm42018-02-131-1/+0
| | | | | | | | | | | 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.
* player: correctly set track information on adding external filesZehua Chen2018-02-101-2/+2
| | | | | | | | 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
* video: fix passing down FPS to vf_vapoursynthwm42018-02-031-2/+0
| | | | | | | To make this less of a mess, remove one of the redundant container_fps fields. Part of #5470.
* audio: move to decoder wrapperwm42018-01-301-8/+2
| | | | | | | | | | | | | | | | Use the decoder wrapper that was introduced for video. This removes all code duplication the old audio decoder wrapper had with the video code. (The audio wrapper was copy pasted from the video one over a decade ago, and has been kept in sync ever since by the power of copy&paste. Since the original copy&paste was possibly done by someone who did not answer to the LGPL relicensing, this should also remove all doubts about whether any of this code is left, since we now completely remove any code that could possibly have been based on it.) There is some complication with spdif handling, and a minor behavior change (it will restrict the list of codecs to spdif if spdif is to be used), but there should not be any difference in practice.
* video: make decoder wrapper a filterwm42018-01-301-12/+2
| | | | | | | | | | | | | | | | | | | | | | | | | Move dec_video.c to filters/f_decoder_wrapper.c. It essentially becomes a source filter. vd.h mostly disappears, because mp_filter takes care of the dataflow, but its remains are in struct mp_decoder_fns. One goal is to simplify dataflow by letting the filter framework handle it (or more accurately, using its conventions). One result is that the decode calls disappear from video.c, because we simply connect the decoder wrapper and the filter chain with mp_pin_connect(). Another goal is to eventually remove the code duplication between the audio and video paths for this. This commit prepares for this by trying to make f_decoder_wrapper.c extensible, so it can be used for audio as well later. Decoder framedropping changes a bit. It doesn't seem to be worse than before, and it's an obscure feature, so I'm content with its new state. Some special code that was apparently meant to avoid dropping too many frames in a row is removed, though. I'm not sure how the source code tree should be organized. For one, video/decode/vd_lavc.c is the only file in its directory, which is a bit annoying.
* player: replace old lavfi wrapper with new filter codewm42018-01-301-7/+9
| | | | | lavfi.c is not necessary anymore, because f_lavfi.c (which was actually converted from it) can be used now.
* audio: rewrite filtering glue codewm42018-01-301-7/+4
| | | | Use the new filtering code for audio too.
* video: rewrite filtering glue codewm42018-01-301-5/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Get rid of the old vf.c code. Replace it with a generic filtering framework, which can potentially handle more than just --vf. At least reimplementing --af with this code is planned. This changes some --vf semantics (including runtime behavior and the "vf" command). The most important ones are listed in interface-changes. vf_convert.c is renamed to f_swscale.c. It is now an internal filter that can not be inserted by the user manually. f_lavfi.c is a refactor of player/lavfi.c. The latter will be removed once --lavfi-complex is reimplemented on top of f_lavfi.c. (which is conceptually easy, but a big mess due to the data flow changes). The existing filters are all changed heavily. The data flow of the new filter framework is different. Especially EOF handling changes - EOF is now a "frame" rather than a state, and must be passed through exactly once. Another major thing is that all filters must support dynamic format changes. The filter reconfig() function goes away. (This sounds complex, but since all filters need to handle EOF draining anyway, they can use the same code, and it removes the mess with reconfig() having to predict the output format, which completely breaks with libavfilter anyway.) In addition, there is no automatic format negotiation or conversion. libavfilter's primitive and insufficient API simply doesn't allow us to do this in a reasonable way. Instead, filters can use f_autoconvert as sub-filter, and tell it which formats they support. This filter will in turn add actual conversion filters, such as f_swscale, to perform necessary format changes. vf_vapoursynth.c uses the same basic principle of operation as before, but with worryingly different details in data flow. Still appears to work. The hardware deint filters (vf_vavpp.c, vf_d3d11vpp.c, vf_vdpaupp.c) are heavily changed. Fortunately, they all used refqueue.c, which is for sharing the data flow logic (especially for managing future/past surfaces and such). It turns out it can be used to factor out most of the data flow. Some of these filters accepted software input. Instead of having ad-hoc upload code in each filter, surface upload is now delegated to f_autoconvert, which can use f_hwupload to perform this. Exporting VO capabilities is still a big mess (mp_stream_info stuff). The D3D11 code drops the redundant image formats, and all code uses the hw_subfmt (sw_format in FFmpeg) instead. Although that too seems to be a big mess for now. f_async_queue is unused.
* player: redo hack for video keyframe seeks with external audiowm42018-01-181-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | If you play a video with an external audio track, and do backwards keyframe seeks, then audio can be missing. This is because a backwards seek can end up way before the seek target (this is just how this seek mode works). The audio file will be seeked at the correct seek target (since audio usually has a much higher seek granularity), which results in silence being played until the video reaches the originally intended seek target. There was a hack in audio.c to deal with this. Replace it with a different hack. The new hack probably works about as well as the old hack, except it doesn't add weird crap to the audio resync path (which is some of the worst code here, so this is some nice preparation for rewriting it). As a more practical advantage, it doesn't discard the audio demuxer packet cache. The old code did, which probably ruined seeking in youtube DASH streams. A non-hacky solution would be handling external files in the demuxer layer. Then chaining the seeks would be pretty easy. But we're pretty far from that, because it would either require intrusive changes to the demuxer layer, or wouldn't be flexible enough to load/unload external files at runtime. Maybe later.
* player: strictly never autoselect tracks from --external-fileswm42018-01-061-0/+1
| | | | | | | | | | | | | | | | Before this commit, some autoselection of tracks coming from files loaded with --external-files was still done. This commit removes all of it, and the only way to select a track is via the explicit stream selection options like --vid/--sid/--aid. I think this was always the original intention. The change could in theory still unintentionally surprise some users, so add a changelog entry. This does not affect --audio-file/--sub-file, even if these contain mismatching track types. E.g. if audio files passed to --audio-file contain subtitles, these should still be selected. Past feature requests indicate that users want this.
* player: use fixed timeout for cache pausing (buffering) durationwm42018-01-031-1/+1
| | | | | | | | | | | | | | | This tried to be clever by waiting for a longer time each time the buffer was underrunning, or shorter if it was getting better. I think this was pretty weird behavior and makes no sense. If the user really wants the stream to buffer longer, he/she/it can just pause the player (the network caches will continue to be filled until they're full). Every time I actually noticed this code triggering in my own use, I didn't find it helpful. Apart from that it was pretty hard to test. Some waiting is needed to avoid that the player just plays the available data as fast as possible (to compensate for late frames and underrunning audio). Just use a fixed wait time, which can now be controlled by the new --cache-pause-wait option.
* options: drop some previously deprecated optionswm42017-12-251-7/+0
| | | | | | | | A release has been made, so drop options deprecated for that release. Also drop some options which have been deprecated a much longer time before. Also fix a typo in client-api-changes.rst.
* player: use start timestamp for ab-looping if --ab-loop-a is absentLeo Izen2017-12-031-0/+1
| | | | | | | If --ab-loop-b is present, then ab-looping will be enabled and will attempt to seek to the beginning of the file. This patch changes it so it will instead seek to the start of playback, either via --start or some equivalent, rather than always to the beginning of the file.
* player: add get_play_start_ptsLeo Izen2017-12-031-0/+1
| | | | | | | | | | Added a get_play_start_pts function to coincide with the already-existing get_play_end_pts. This prevents code duplication and also serves to make it so code that probes the start time (such as get_current_pos_ratio) will work correctly with chapters. Included is a bug fix for misc.c/rel_time_to_abs that makes it work correctly with chapters when --rebase-start-time=no is set.
* audio: make libaf derived code optionalwm42017-09-211-0/+6
| | | | | | | | | | | | | | | This code could not be relicensed. The intention was to write new filter code (which could handle both audio and video), but that's a bit of work. Write some code that can do audio conversion (resampling, downmixing, etc.) without the old audio filter chain code in order to speed up the LGPL relicensing. If you build with --disable-libaf, nothing in audio/filter/* is compiled in. It breaks a few features, such as --volume, --af, pitch correction on speed changes, replaygain. Most likely this adds some bugs, even if --disable-libaf is not used. (How the fuck does EOF notification work again anyway?)
* options: remove --heartbeat-cmd and --heartbeat--intervalwm42017-09-181-1/+0
| | | | | | | | | This mechanism uses system() and shouldn't even exist. x11_common.c has its own solution for the original problem (disabling Linux DE screensavers without MPlayer/mpv having to link a dbus lib). If that is not sufficient, you can create a simple Lua script. Incidentally fixes #4888.
* video: change --deinterlace behaviorwm42017-08-221-3/+1
| | | | | | | | | | | | This removes all GPL only code from it, and that's the whole purpose. Also happens to be much simpler. The "deinterlace" option still sort of exists, but only as runtime changeable option. The main change in behavior is that the property will not report back the actual deint state. Or in other words, if inserting or initializing the filter fails, the deinterlace property will still return "yes". This is in line with most recent behavior changes to properties and options.
* audio: introduce a new type to hold audio frameswm42017-08-161-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is pretty pointless, but I believe it allows us to claim that the new code is not affected by the copyright of the old code. This is needed, because the original mp_audio struct was written by someone who has disagreed with LGPL relicensing (it was called af_data at the time, and was defined in af.h). The "GPL'ed" struct contents that surive are pretty trivial: just the data pointer, and some metadata like the format, samplerate, etc. - but at least in this case, any new code would be extremely similar anyway, and I'm not really sure whether it's OK to claim different copyright. So what we do is we just use AVFrame (which of course is LGPL with 100% certainty), and add some accessors around it to adapt it to mpv conventions. Also, this gets rid of some annoying conventions of mp_audio, like the struct fields that require using an accessor to write to them anyway. For the most part, this change is only dumb replacements of mp_audio related functions and fields. One minor actual change is that you can't allocate the new type on the stack anymore. Some code still uses mp_audio. All audio filter code will be deleted, so it makes no sense to convert this code. (Audio filters which are LGPL and which we keep will have to be ported to a new filter infrastructure anyway.) player/audio.c uses it because it interacts with the old filter code. push.c has some complex use of mp_audio and mp_audio_buffer, but this and pull.c will most likely be rewritten to do something else.
* player: make refresh seeks slightly more robustwm42017-08-141-10/+11
| | | | | | | | | | | | | | | | | | | | | | Refresh seeks are automatically issued when changing filters, which improves user experience if these filters change buffering or such. The refresh seek could actually overwrite a previously ongoing seek: set pause yes set time-pos 10 set vf "" Here, the video code issued a refresh seek to the previous video position, which could be different from the previously triggered (and still ongoing) seek, this overwriting the seek. Factor all refresh seek handling into a new function, and make it handle ongoing seeks correctly. Remove the weird new canonical_pts field, which actually had no use. Fixes #4757.
* player: make --lavfi-complex changeable at runtimewm42017-08-121-3/+6
| | | | | | | | Tends to be somewhat glitchy if subtitles are enabled, and you enable and disable tracks. On error, this will disable --lavfi-complex, which will result in whatever behavior.
* scripting: add wrapper to load scripts with user pathsRicardo Constantino2017-06-301-0/+1
| | | | | Fixes regression since b2f756c80e, which broke load-script command when used with user paths (ex: ~~/script.lua)
* player: change license of most core files to LGPLwm42017-06-231-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These files have all in common that they were fully or mostly taken from mplayer.c. (mplayer.c was a huge file that contains almost all of the playback core, until it was split into multiple parts.) This was probably the hardest part to relicense, because so much code was moved around all the time. player/audio.c still does not compile. We'll have to redo audio filtering. Once that is done, we can probably actually provide an actual LGPL configure switch. Here is a relatively detailed list of potential issues: 8d190244: author did not reply, parts were made GPL-only in a previous commit. 7882ea9b: author could not be reached, but the code is gone. wscript still has --datadir switch, but I don't think this is relevant to copyright. f197efd5: unclear origin, but I consider the code gone anyway (replaced with generic OSD mechanisms). 8337d9c2: author did not reply, but only the option still exists (under a different name), other code was removed. d8fd7131: did not reply. Disabled in a previous commit. 05258251: same author as above. Both fields actually seem to have vanished (even when tracking renames), so no action taken. d459