summaryrefslogtreecommitdiffstats
path: root/player/loadfile.c
Commit message (Collapse)AuthorAgeFilesLines
* Merge commit '559a400ac36e75a8d73ba263fd7fa6736df1c2da' into ↵Anton Kindestam2018-12-051-75/+280
|\ | | | | | | | | | | wm4-commits--merge-edition This bumps libmpv version to 1.103
| * demux, stream: rip out the classic stream cachewm42018-08-311-1/+0
| | | | | | | | | | | | The demuxer cache is the only cache now. Might need another change to combat seeking failures in mp4 etc. The only bad thing is the loss of cache-speed, which was sort of nice to have.
| * HACK: prefetch subtitles on track switch a bit morewm42018-06-301-1/+4
| | | | | | | | To get overlapping shit etc.
| * player: don't cache subtitles across deselectionwm42018-06-301-5/+1
| | | | | | | | | | This means reselection triggers full reinit. This is better if you have options that "edit" subtitles or whatever.
| * player: get rid of mpv_global.optswm42018-05-241-1/+2
| | | | | | | | | | | | | | | | This was always a legacy thing. Remove it by applying an orgy of mp_get_config_group() calls, and sometimes m_config_cache_alloc() or mp_read_option_raw(). win32 changes untested.
| * player: make playback termination asynchronouswm42018-05-241-20/+107
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Until now, stopping playback aborted the demuxer and I/O layer violently by signaling mp_cancel (bound to libavformat's AVIOInterruptCB mechanism). Change it to try closing them gracefully. The main purpose is to silence those libavformat errors that happen when you request termination. Most of libavformat barely cares about the termination mechanism (AVIOInterruptCB), and essentially it's like the network connection is abruptly severed, or file I/O suddenly returns I/O errors. There were issues with dumb TLS warnings, parsers complaining about incomplete data, and some special protocols that require server communication to gracefully disconnect. We still want to abort it forcefully if it refuses to terminate on its own, so a timeout is required. Users can set the timeout to 0, which should give them the old behavior. This also removes the old mechanism that treats certain commands (like "quit") specially, and tries to terminate the demuxers even if the core is currently frozen. This is for situations where the core synchronized to the demuxer or stream layer while network is unresponsive. This in turn can only happen due to the "program" or "cache-size" properties in the current code (see one of the previous commits). Also, the old mechanism doesn't fit particularly well with the new one. We wouldn't want to abort playback immediately on a "quit" command - the new code is all about giving it a chance to end it gracefully. We'd need some sort of watchdog thread or something equally complicated to handle this. So just remove it. The change in osd.c is to prevent that it clears the status line while waiting for termination. The normal status line code doesn't output anything useful at this point, and the code path taken clears it, both of which is an annoying behavior change, so just let it show the old one.
| * player: change the role of the "stop_play" and "playing" variablewm42018-05-241-11/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: move a function (no functional changes)wm42018-05-241-7/+7
| |
| * player: some further cleanup of the mp_cancel crapwm42018-05-241-46/+14
| | | | | | | | | | | | | | | | | | | | Alway give each demuxer its own mp_cancel instance. This makes management of the mp_cancel things much easier. Also, instead of having add/remove functions for mp_cancel slaves, replace them with a simpler to use set_parent function. Remove cancel_and_free_demuxer(), which had mpctx as parameter only to check an assumption. With this commit, demuxers have their own mp_cancel, so add demux_cancel_and_free() which makes use of it.
| * demux: get rid of free_demuxer[_and_stream]()wm42018-05-241-1/+1
| | | | | | | | | | | | | | Them being separate is just dumb. Replace them with a single demux_free() function, and free its stream by default. Not freeing the stream is only needed in 1 special case (demux_disc.c), use a special flag to not free the stream in this case.
| * player: simplify edition switchingwm42018-05-241-10/+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-47/+62
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * player: don't reset last_seek_pts on playback state resetwm42018-05-241-3/+2
| | | | | | | | | | | | | | | | | | | | | | This is nonsense. Didn't matter in most situations, because seeking itself set this after it was cleared. But some callers don't do this, see e.g. commit ed73ba89644fc6. There is no need to clear it at all, and it causes issues with the next commit. It only needs to be reset on loading. Also move the initialization on loading up, which doesn't change behavior, but makes the intention clearer.
| * client API: kill async commands on terminationwm42018-05-241-1/+4
| | | | | | | | | | | | | | | | | | | | | | 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/+51
| | | | | | | | | | | | | | | | | | | | | | | | 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-8/+8
| | | | | | | | | | | | 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-16/+77
| | | | | | | | | | Still missing: not freezing when removing a track (i.e. closing demuxer) with the sub-remove/audio-remove/rescan-external-files commands.
| * player: make abort during loading faster if ytdl_hook is usedwm42018-05-241-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Basically, the ytdl_hook script will not terminate the script, even if you change to a new playlist entry. This happens because ytdl_hook keeps the player core in an early loading stage, and the forceful playback abort is done only in the ermination code. This does not handle the "stop" and "quit" commands, which can still take longer than expected, but on the other hand have some weird special handling (see below). I'm not doing this out of laziness. Playback stopping will have to be somewhat redone anyway. Basically we want to give everything a chance to terminate, and if it doesn't work, we want to stop loading or playback forcefully after a small timeout. We also want to remove the mess with input.c's special handling of "quit" and some other commands (see abort_playback_cb stuff).
| * player: don't even start loading external tracks when aborting loadingwm42018-05-241-1/+1
| | | | | | | | | | | | It seems the ytdl script like to continue loading external tracks even if loading was aborted. Trying to do so will still quickly fail, but not without a load of log noise. So check and error out early.
| * command: make sub-add and audio-add commands asyncwm42018-05-241-4/+16
| | | | | | | | | | | | | | | | | | | | 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.
* | encode: fix expected streams when using --lavfi-complexTSaaristo2018-09-261-8/+8
| | | | | | | | | | | | | | | | | | mpctx->current_track[0][STREAM_VIDEO] (and STREAM_AUDIO) are empty when using --lavfi-complex. Moving the muxer stream hinting after audio/video chain initialization and checking if the chains exist fixes encoding with --lavfi-complex. Previously, the output audio/video streams did not get prepared and the encode would fail due to unexpected stream addition.
* | player: expose hearing/visual impaired flags on audio tracksAman Gupta2018-08-131-0/+3
| | | | | | | | Signed-off-by: Aman Gupta <aman@tmm1.net>
* | player: simplify edition switchingwm42018-05-311-10/+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.
* build: make encoding mode non-optionalwm42018-05-031-9/+4
| | | | Makes it easier to not break the build by confusing the ifdeffery.
* encode: rewrite half of itwm42018-04-291-2/+16
| | | | | | | | | | | | | 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.
* scripting: change when/how player waits for scripts being loadedwm42018-04-181-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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).
* player: fix hook processing consistency and code duplication issueswm42018-03-261-43/+16
| | | | | | | | | | | | | | | | | | | | | | | | 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-261-3/+3
| | | | | | | | | | | | | | | 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.
* player: don't print error if aborted while loading external fileswm42018-03-261-1/+2
|
* 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.
* player: set thread name in opener threadwm42018-03-031-0/+3
| | | | Somewhat helpful for debugging.
* player: correctly set track information on adding external filesZehua Chen2018-02-101-14/+18
| | | | | | | | 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 confusing thing is that many filters (including track->dec) have a public struct, but to free them, you need to free the mp_filter pointer itself (track->dec->f). The assignment wrote to a dangling pointer, instead of removing the dangling pointer. (Other than that, this idiom is actually nice.)
* loadfile: remove minor unneeded things from --lavfi-complex setupwm42018-02-031-3/+1
|
* audio: move to decoder wrapperwm42018-01-301-20/+10
| | | | | | | | | | | | | | | | 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-14/+13
| | | | | | | | | | | | | | | | | | | | | | | | | 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.
*