summaryrefslogtreecommitdiffstats
path: root/player/misc.c
Commit message (Collapse)AuthorAgeFilesLines
* player: add ab-loop-count option/propertywm42020-02-081-0/+3
| | | | | | | | | | | | As requested I guess. It behaves quite similar to the --loop* options. Not quite happy with the idea that 1) the option is mutated on each operation (but at least it's consistent with --loop* and doesn't require more properties), and 2) the ab-loop command will do nothing once all loop iterations are done. As a concession, the OSD shows something about "disabled". Fixes: #7360
* playlist: change from linked list to an arraywm42019-12-281-3/+4
| | | | | | | | | | | | | | | | | | | Although a linked list was ideal at first, there are cases where it sucks, and became increasingly awkward (with the mpv command API preferring integer indexes to access the list). In future, we probably want to add more playlist-related functionality, so better change it to an array now. An array isn't always ideal either. Since playlist entries are still separate objects (because in some cases you need a stable "iterator" to it), but you still need to efficiently get the next/previous playlist entry, there's a pl_index field, that needs to be maintained. E.g. adding an entry at the start of the playlist => update the pl_index field for all other entries. Well, it's not really worth to do something more complicated to avoid these things. This commit is probably buggy as shit. It's not like I bothered to test everything. That's _your_ role.
* stream, demux: redo origin policy thingwm42019-12-201-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | mpv has a very weak and very annoying policy that determines whether a playlist should be used or not. For example, if you play a remote playlist, you usually don't want it to be able to read local filesystem entries. (Although for a media player the impact is small I guess.) It's weak and annoying as in that it does not prevent certain cases which could be interpreted as bad in some cases, such as allowing playlists on the local filesystem to reference remote URLs. It probably barely makes sense, but we just want to exclude some other "definitely not a good idea" things, all while playlists generally just work, so whatever. The policy is: - from the command line anything is played - local playlists can reference anything except "unsafe" streams ("unsafe" means special stream inputs like libavfilter graphs) - remote playlists can reference only remote URLs - things like "memory://" and archives are "transparent" to this This commit does... something. It replaces the weird stream flags with a slightly clearer "origin" value, which is now consequently passed down and used everywhere. It fixes some deviations from the described policy. I wanted to force archives to reference only content within them, but this would probably have been more complicated (or required different abstractions), and I'm too lazy to figure it out, so archives are now "transparent" (playlists within archives behave the same outside). There may be a lot of bugs in this. This is unfortunately a very noisy commit because: - every stream open call now needs to pass the origin - so does every demuxer open call (=> params param. gets mandatory) - most stream were changed to provide the "origin" value - the origin value needed to be passed along in a lot of places - I was too lazy to split the commit Fixes: #7274
* player: simplify --stream-dump codewm42019-10-311-4/+4
| | | | | Not sure why it was so complicated. It avoided allocation data on the stack and copying it twice, but who cares.
* player: fix --loop with backward playbackwm42019-09-191-8/+2
| | | | | | | | | | | Obviously should seek back to the end of the file when it loops. Also remove some minor code duplication around start times. This isn't the correct solution by the way. Rather than hoping we know a reasonable start/end time, this stuff should instruct the demuxer to seek to the exact location. It'll work with 99% of all normal files, but add an appropriate comment (that basically says the function is bullshit) to get_start_time() anyway.
* player: modify/simplify AB-loop behaviorwm42019-09-191-47/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This changes the behavior of the --ab-loop-a/b options. In addition, it makes it work with backward playback mode. The most obvious change is that the both the A and B point need to be set now before any looping happens. Unlike before, unset points don't implicitly use the start or end of the file. I think the old behavior was a feature that was explicitly added/wanted. Well, it's gone now. This is because of 2 reasons: 1. I never liked this feature, and it always got in my way (as user). 2. It's inherently annoying with backward playback mode. In backward playback mode, the user wants to set A/B in the wrong order. The ab-loop command will first set A, then B, so if you use this command during backward playback, A will be set to a higher timestamps than B. If you switch back to forward playback mode, the loop would stop working. I want the loop to just continue to work, and the chosen solution conflicts with the removed feature. The order issue above _could_ be fixed by also switching the AB-loop user option values around on direction switch. But there are no other instances of option changes magically affecting other options, and doing this would probably lead to unexpected misery (dying from corner cases and such). Another solution is sorting the A/B points by timestamps after copying them from the user options. Then A/B options set in backward mode will work in forward mode. This is the chosen solution. If you sort the points, you don't know anymore whether the unset point is supposed to signify the end or the start of the file. The AB-loop code is slightly better abstracted now, so it should be easy to restore the removed feature. It would still require coming up with a solution for backwards playback, though. A minor change is that if one point is set and the other is unset, I'm rendering both the chapter markers and the marker for the set point. Why? I don't know. My test file had chapters, and I guess I decided this looked better. This commit also fixes some subtle and obvious issues that I already forgot about when I wrote this commit message. It cleans up some minor code duplication and nonsense too. Regarding backward playback, the code uses an unsanitary mix of internal ("transformed") and user timestamps. So the play_dir variable appears more than usual. To mention one unfixed issue: if you set an AB-loop that is completely past the end of the file, it will get stuck in an infinite seeking loop once playback reaches the end of the file. Fixing this reliably seemed annoying, so the fix is "just don't do this". It's not a hard freeze anyway.
* player: simplify/fix --start/--end handling with --rebase-start-time=nowm42019-09-191-20/+10
| | | | | | | | | | | | | | | | | | | | | | The get_play_start_pts() function was supposed to return "rebased" (relative to 0) timestamps. This was roundabout, because one of 2 callers just added the offset back, and the other caller actually expected an absolute timestamp. Change rel_time_to_abs() (whose return value get_play_start_pts() returns without further changes) to return absolute times. This should fix that absolute and relative times passed to --start and --end were treated the same, which can't be right. It probably also fixes --end if --rebase-start-time=no is used (which can't have been correct either). All in all I'm not sure why --rebase-start-time=no or absolute vs. relative times in --start/--end even exist, when they were incorrectly implemented for years. Untested, because no sample file and I don't care. However, if anyone cares, and I got it wrong, I hope it's simple to fix.
* player: minor --end simplificationwm42019-09-191-4/+1
|
* options: remove --chapterwm42019-09-191-23/+1
| | | | | | | | | Has been deprecated for almost 3 years. Manpage didn't mention the deprecation, but CLI and release notes did. It wouldn't be much effort to keep this option working, but I just don't see the damn point. --start/--end can specify chapters using special syntax, which is equivalent.
* player: make a function staticwm42019-09-191-1/+1
|
* stream: redo buffer handling and allow arbitrary size for stream_peek()wm42019-09-191-1/+1
| | | | | | | | | | | | | | | | struct stream used to include the stream buffer, including peek buffer, inline in the struct. It could not be resized, which means the maximum peek size was set in stone. This meant demux_lavf.c could peek only so much data. Change it to use a dynamic buffer. Because it's possible, keep the inline buffer for default buffer sizes (which are basically always used outside of file opening). It's unknown whether it really helps with anything. Probably not. This is also the fallback plan in case we need something like the old stream cache in order to deal with mp4 + unseekable http: the code can now be easily changed to use any buffer size.
* demux, stream: rip out the classic stream cachewm42018-08-311-18/+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.
* player: use canonical playback time for video refresheswm42018-05-241-4/+1
| | | | | | | | | | | | | | | | When changing video filters during initialization, there was a small time window where video was initialized, but playback restart was not complete yet. In this time window, playback_pts is not set. But since issue_refresh_seek() was using this, it could lead to no refresh being done _if_ the "video" had only 1 frame (such as cover art). Fix this by using get_current_time() instead, which is the current time with corner cases such as ongoing loading or seeks taken into account. See also the previous commit. Without that, get_current_time() could return NOPTS during init. Fixes #5831.
* options: move most subtitle and OSD rendering options to sub structswm42018-01-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Remove them from the big MPOpts struct and move them to their sub structs. In the places where their fields are used, create a private copy of the structs, instead of accessing the semi-deprecated global option struct instance (mpv_global.opts) directly. This actually makes accessing these options finally thread-safe. They weren't even if they should have for years. (Including some potential for undefined behavior when e.g. the OSD font was changed at runtime.) This is mostly transparent. All options get moved around, but most users of the options just need to access a different struct (changing sd.opts to a different type changes a lot of uses, for example). One thing which has to be considered and could cause potential regressions is that the new option copies must be explicitly updated. sub_update_opts() takes care of this for example. Another thing is that writing to the option structs manually won't work, because the changes won't be propagated to other copies. Apparently the only affected case is the implementation of the sub-step command, which tries to change sub_delay. Handle this one explicitly (osd_changed() doesn't need to be called anymore, because changing the option triggers UPDATE_OSD, and updates the OSD as a consequence). The way the option value is propagated is rather hacky, but for now this will do.
* player/misc.c: allow both --length and --end to control play endpointLeo Izen2017-12-041-2/+3
| | | | | | | | | | Most options that change the playback endpoint coexist and playback stops when it reaches any of them. (e.g. --ab-loop-b, --end, or --chapter). This patch extends that behavior to --length so it isn't automatically trumped by --end if both are present. These two will interact now as the other options do. This change is also documented in DOCS/man/options.rst.
* player: use start timestamp for ab-looping if --ab-loop-a is absentLeo Izen2017-12-031-1/+30
| | | | | | | 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-3/+49
| | | | | | | | | | 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.
* player: make refresh seeks slightly more robustwm42017-08-141-0/+19
| | | | | | | | | | | | | | | | | | | | | | 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: remove --stream-capture option/propertywm42017-01-211-4/+18
| | | | | | | | | | | | | | | This was excessively useless, and I want my time back that was needed to explain users why they don't want to use it. It captured the byte stream only, and even for types of streams it was designed for (like transport streams), it was rather questionable. As part of the removal, un-inline demux_run_on_thread() (which has only 1 call-site now), and sort of reimplement --stream-dump to write the data directly instead of using the removed capture code. (--stream-dump is also very useless, and I struggled coming up with an explanation for it in the manpage.)
* player: add prefetching of the next playlist entrywm42017-01-181-49/+0
| | | | | | | | | | | | Since for mpv CLI, the player state is a singleton, full prefetching is a bit tricky. We do it only on the demuxer layer. The implementation reuses the old "open thread". This means there is significant potential for regressions even if the new option is not used. This is made worse by the fact that I barely tested this code. The generic mpctx_run_reentrant() wrapper is also removed - this was its only user, and its remains become part of the new implementation.
* player: restructure cancel callbackwm42017-01-181-1/+1
| | | | | | | | | | | | As preparation for file prefetching, we basically have to get rid of using mpctx->playback_abort for the main demuxer (i.e. the thing that can be prefetched). It can't be changed on a running demuxer, and always using the same cancel handle would either mean aborting playback would also abort prefetching, or that playback can't be aborted anymore. Make this more flexible with some refactoring. Thi is a quite shitty solution if you ask me, but YOLO.
* player: litter code with explicit wakeup callswm42016-09-161-2/+4
| | | | | | | | | | | | | This does 3 kinds of changes: - change sleeptime=x to mp_set_timeout() - change sleeptime=0 to mp_wakeup_core() calls (to be more explicit) - change commands etc. to call mp_wakeup_core() if they do changes that require the playloop to be rerun This is preparation for the following changes. The goal is to process client API requests without having to rerun the playloop every time. As of this commit, the changes should not change behavior. In particular, the playloop is still implicitly woken up on every command.
* player, ao, vo: don't call mp_input_wakeup() directlywm42016-09-161-1/+1
| | | | | | | | | | | | | Currently, calling mp_input_wakeup() will wake up the core thread (also called the playloop). This seems odd, but currently the core indeed calls mp_input_wait() when it has nothing more to do. It's done this way because MPlayer used input_ctx as central "mainloop". This is probably going to change. Remove direct calls to this function, and replace it with mp_wakeup_core() calls. ao and vo are changed to use opaque callbacks and not use input_ctx for this purpose. Other code already uses opaque callbacks, or has legitimate reasons to use input_ctx directly (such as sending actual user input).
* stream, demux, config: remove some dead/unneeded option-related codewm42016-09-091-17/+0
| | | | | | | | | | This has all been made unnecessary recently. The change not to copy the global option struct in particular can be made because now nothing accesses the global options anymore in the demux and stream layers. Some code that was accidentally added/changed in commit 5e30e7a0 is also removed, because it was simply committed accidentally, and was never used.
* m_config: introduce basic mechanism to synchronize global option updateswm42016-09-021-0/+1
| | | | | | | | | | | | | | | | | | The way option runtime changes are handled is pretty bad in the current codebase. There's a big option struct (MPOpts), which contains almost everything, and for which no synchronization mechanism exists. This was handled by either making some options read-only after initialization, duplicating the option struct, using sub-options (in the VO), and so on. Introduce a mechanism that creates a copy of the global options (or parts of it), and provides a well-defined way to update them in a thread-safe way. Most code can remain the same, just that all the component glue code has to explicitly make use of it first. There is still lots of room for improvement. For example, the update mechanism could be better.
* player: don't send win32 taskbar update before window is createdwm42016-09-021-1/+1
| | | | | | | | | | | | | | | | | | If the win32 taskbar progress update is sent before the VO window is created, then w32_common.c will ignore it because the actual taskbar object was not created yet. (At least this is what I suspect happens. The window is already created at this point, but not mapped.) Hopefully fix this is fixed by creating until after the window is created, i.e. the VO has been configured at least once. Untested (who wants to boot into Windows just to wait until it has applied all of its stupid updates). Also not explicit is whether update_vo_playback_state() will actually be called soon enough in all cases. It probably is. Probably fixes #3482.
* options: make mp_vo_opts options an actual sub-option groupwm42016-08-301-1/+1
| | | | | | | | | | | Just a minor refactor along the planned option change. This commit will make it easier to update (i.e. copy) the VO options without copying _all_ options. For now, behavior should be equivalent, though. (The VO options were put into a separate struct quite early - when all global variables were removed from the source code. It wasn't clear whether the separate struct would have any actual purpose, but it seems it will now. Awesome, huh.)
* player: update Windows playback state asynchronouslywm42016-08-201-2/+2
| | | | | | | | | | | | | | | | | | Doing this required synchronizing with the VO thread, which could lead to audio dropouts if the VO was frozen (which can happen in practice if e.g. an opengl_cb user is not doing what the API demands). Add a way to send asynchronous VOCTRLs, and use that for the playback state. In theory, it would be better to make this status update a several function and to "merge" several queued update, but that would be slightly more effort/code, and the update is so infrequent that the merging would never happen anyway. The change to vo_destroy() is to make sure all queued asynchronous reuqests are finished before making the vo_thread exit. Even though it's only used on MS Windows, it's run on any platform with any VO, which makes this worse.
* player: make looping slightly more seamlesswm42016-08-181-0/+6
| | | | | | This affects A-B loops and --loop-file, and audio. Instead of dropping audio by resetting the AO, try to make it seamless by not sending data after the loop point, and after the seek send new data without a reset.
* player: offset demuxer on start/seek properly with audio/sub delaywm42016-08-041-0/+12
| | | | | | | | | | | | | | | | | Assume you use a large value like --audio-delay=20. Then until now the player would just have seeked normally to a "too late" position, and played silence for about 20 seconds until audio in the correct time range is coming again. Change this by offsetting seeks by the right amount. This works for both external and muxed files. If a seek isn't precise, then it works only for external files. This might cause issues with very large delay options. Hr-seek skipping could take a lot of time (especially because it affects video too), the demuxer queue could overflow, and other weird corner cases could appear. But we just try this on best-effort basis, and if the user uses extreme values we don't guarantee good behavior.
* win32: make taskbar progress indication optionalmaniak13492016-05-081-4/+12
| | | | | | | | | | | Add --taskbar-progress command line option and property which controls taskbar progress indication rendering in Windows 7+. This option is on by default and can be toggled during playback. This option does not affect the creation process of ITaskbarList3. When the option is turned off the progress bar is just hidden with TBPF_NOPROGRESS. Closes #2535
* cache: use a single STREAM_CTRL for various cache infowm42016-03-291-11/+8
| | | | | | | | Instead of having a separate for each, which also requires separate additional caching in the demuxer. (The demuxer adds an indirection, since STREAM_CTRLs are not thread-safe.) Since this includes the cache speed, this should fix #3003.
* player: simplify error_on_track()wm42016-02-051-15/+13
| | | | | | track can't be NLUL at this point, so the if is redundant. Remove it and unindent the block. Also, make the function check whether the track is selected at all, which makes it safer and idempotent.
* player: refactor: reduce some dependencies on current_trackwm42016-02-011-2/+1
| | | | Don't mind me.
* Relicense some non-MPlayer source files to LGPL 2.1 or laterwm42016-01-191-15/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This covers source files which were added in mplayer2 and mpv times only, and where all code is covered by LGPL relicensing agreements. There are probably more files to which this applies, but I'm being conservative here. A file named ao_sdl.c exists in MPlayer too, but the mpv one is a complete rewrite, and was added some time after the original ao_sdl.c was removed. The same applies to vo_sdl.c, for which the SDL2 API is radically different in addition (MPlayer supports SDL 1.2 only). common.c contains only code written by me. But common.h is a strange case: although it originally was named mp_common.h and exists in MPlayer too, by now it contains only definitions written by uau and me. The exceptions are the CONTROL_ defines - thus not changing the license of common.h yet. codec_tags.c contained once large tables generated from MPlayer's codecs.conf, but all of these tables were removed. From demux_playlist.c I'm removing a code fragment from someone who was not asked; this probably could be done later (see commit 15dccc37). misc.c is a bit complicated to reason about (it was split off mplayer.c and thus contains random functions out of this file), but actually all functions have been added post-MPlayer. Except get_relative_time(), which was written by uau, but looks similar to 3 different versions of something similar in each of the Unix/win32/OSX timer source files. I'm not sure what that means in regards to copyright, so I've just moved it into another still-GPL source file for now. screenshot.c once had some minor parts of MPlayer's vf_screenshot.c, but they're all gone.
* global: add client API pointer to library handlewm42016-01-151-0/+1
| | | | | | | Makes the next commit simpler. It's probably a bad idea to add more fields to the global state, but on the other hand the client API state is pretty much per-instance anyway. It also will help with things like the proposed libmpv custom stream API.
* mpv_talloc.h: rename from talloc.hDmitrij D. Czarkoff2016-01-111-1/+1
| | | | This change helps avoiding conflict with talloc.h from libtalloc.
* player: eliminate demux_get_next_pts()wm42016-01-111-14/+0
| | | | | | | | | | | | | | | | This slightly changes behavior when seeking with external audio/subtitle tracks if transport streams and mpeg files are played, as well as behavior when seeking with such external tracks. get_main_demux_pts() is evil because it always blocks on the demuxer (if there isn't already a packet queued). Thus it could lock up the player, which is a shame because all other possible causes have been removed. The reduced "precision" when seeking in the ts/mpeg cases (where SEEK_FACTOR is used, resulting in byte seeks instead of timestamp seeks) might lead to issues. We should probably drop this heuristic. (It was introduced because there is no other way to seek in files with PTS resets with libavformat, but its value is still questionable.)
* demux: remove weird tripple-buffering for the sh_stream listwm42015-12-231-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The demuxer infrastructure was originally single-threaded. To make it suitable for multithreading (specifically, demuxing and decoding on separate threads), some sort of tripple-buffering was introduced. There are separate "struct demuxer" allocations. The demuxer thread sets the state on d_thread. If anything changes, the state is copied to d_buffer (the copy is protected by a lock), and the decoder thread is notified. Then the decoder thread co