summaryrefslogtreecommitdiffstats
path: root/player/misc.c
Commit message (Collapse)AuthorAgeFilesLines
* 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 copies the state from d_buffer to d_user (again while holding a lock). This avoids the need for locking in the demuxer/decoder code itself (only demux.c needs an internal, "invisible" lock.) Remove the streams/num_streams fields from this tripple-buffering schema. Move them to the internal struct, and protect them with the internal lock. Use accessors for read access outside of demux.c. Other than replacing all field accesses with accessors, this separates allocating and adding sh_streams. This is needed to avoid race conditions. Before this change, this was awkwardly handled by first initializing the sh_stream, and then sending a stream change event. Now the stream is allocated, then initialized, and then declared as immutable and added (at which point it becomes visible to the decoder thread immediately). This change is useful for PR #2626. And eventually, we should probably get entirely of the tripple buffering, and this makes a nice first step.
* win32: don't show progress indicator in idle modeJames Ross-Gowan2015-11-231-1/+3
|
* player: use demuxer ts offset to simplify timeline ts handlingwm42015-11-161-8/+0
| | | | | | | | | Use the demux_set_ts_offset() added in the previous commit to base each timeline segment to use timestamps according to its relative position within the overall timeline. As a consequence we don't need to care about these timestamps anymore, and everything becomes simpler. (Another minor but delicious nugget of sanity.)
* player: handle rebasing start time differentlywm42015-11-161-14/+5
| | | | | | | | | | | | | | | | Most of this is explained in the DOCS additions. This gives us slightly more sanity, because there is less interaction between the various parts. The goal is getting rid of the video_offset entirely. The simplification extends to the user API. In particular, we don't need to fix missing parts in the API, such as the lack for a seek command that seeks relatively to the start time. All these things are now transparent. (If someone really wants to know the real timestamps/start time, new properties would have to be added.)
* win32: support taskbar button progress indicatorMartin Herkt2015-11-151-0/+20
| | | | | | | | | | | This adds support for the progress indicator taskbar extension that was introduced with Windows 7 and Windows Server 2008 R2. I don’t like this solution because it keeps its own state and introduces another VOCTRL, but I couldn’t come up with anything less messy. closes #2399
* stream: provide a stream_get_size() convenience functionwm42015-08-181-2/+1
| | | | | And use it everywhere, instead of retrieving the size manually. Slight simplification.
* player: never overwrite stop_play fieldwm42015-07-081-1/+2
| | | | | | | This is a real pain: if a quit command is received, it's set to PT_QUIT. And then other code could overwrite it, making it not quit. The annoying bit is that stop_play is written and read in many places. Just not overwriting it unconditionally seems to be the best course of action.
* player: unentangle --stream-dumpwm42015-07-021-5/+8
| | | | | | | | The final goal is making opening the demuxer and opening the stream the same operation. Stream dumping is a rather uninteresting feature, but has a small number of vocal users, and it's easy to keep.
* Update license headersMarcin Kurczewski2015-04-131-5/+4
| | | | Signed-off-by: wm4 <wm4@nowhere>
* player: cosmetics: async/non-blocking -> reentrantwm42015-02-201-2/+2
| | | | | | These functions do blocking work on a separate thread, but wait until they return. So they are not async or non-blocking. But they do react to user-input and client API accesses, which makes them reentrant.
* player: don't display zero duration for files with unknown durationwm42014-10-291-2/+2
| | | | | | On OSD/terminal, just don't display the duration if unavailable. Make the "length" property unavailable if duration is unavailable.
* player: add an option to abort playback on partial init failureswm42014-10-281-2/+3
| | | | | | This is probably what libmpv users want; and it also improves error reporting (or we'd have to add a way to communicate such mid-playback failures as events).
* client API: better error reportingwm42014-10-281-2/+5
| | | | Give somewhat more information on playback failure.
* player: fix exiting if both audio and video fail initializingwm42014-10-231-0/+18
| | | | | | | | | | | | | The player was supposed to exit playback if both video and audio failed to initialize (or if one of the streams was not selected when the other stream failed). This didn't work; for one this check was missing from one of the failure paths. And more importantly, both checked the current_track array incorrectly. Fix these issues, and move the failure handling code into a common function. CC: @mpv-player/stable
* Set thread name for debuggingwm42014-10-191-0/+2
| | | | | | | | | | Especially with other components (libavcodec, OSX stuff), the thread list can get quite populated. Setting the thread name helps when debugging. Since this is not portable, we check the OS variants in waf configure. old-configure just gets a special-case for glibc, since doing a full check here would probably be a waste of effort.
* player: open stream and demuxer asynchronouslywm42014-10-061-0/+64
| | | | | | | | | | | | | | | | | | | | | | | | | Run opening the stream and opening the demuxer in a separate thread. This should remove the last code paths in which the player can normally get blocked on network. When the stream is opened, the player will still react to input and so on. Commands to abort opening can also be handled properly, instead of using some of the old hacks in input.c. The only thing the user can really do is aborting loading by navigating the playlist or quitting. Whether playback abort works depends on the stream implementation; with normal network, this will depend on what libavformat (via "interrupt" callback) does. Some pain is caused by DVD/BD/DVB. These want to reload the demuxer sometimes. DVB wants it in order to discard old, inactive streams. DVD/BD for the same reason, and also for reloading stream languages and similar metadata. This means the stream and the demuxer have to be loaded separately. One minor detail is that we now need to copy all global options. This wasn't really needed before, because the options were accessed on opening only, but since opening is now on a separate thread, this obviously becomes a necessity.
* player: move code to make playloop smallerwm42014-09-251-3/+9
| | | | | This is basically a cosmetic change, although it weirdly also affects the percent position in encoding mode.
* player: some more input refactoringwm42014-09-071-7/+1
| | | | | | | | | | | | | | | | | Continues commit 348dfd93. Replace other places where input was manually fetched with common code. demux_was_interrupted() was a weird function; I'm not entirely sure about its original purpose, but now we can just replace it with simpler code as well. One difference is that we always look at the command queue, rather than just when cache initialization failed. Also, instead of discarding all but quit/playlist commands (aka abort command), run all commands. This could possibly lead to unwanted side-effects, like just ignoring commands that have no effect (consider pressing 'f' for fullscreen right on start: since the window is not created yet, it would get discarded). But playlist navigation still works as intended, and some if not all these problems already existed before that in some forms, so it should be ok.
* player: use virtual time for --audio-file with ordered chapterswm42014-08-151-0/+10
| | | | | | | | | Apparently users prefer this behavior. It was used for subtitles too, so move the code to calculate the video offset into a separate function. Seeking also needs to be fixed. Fixes #1018.
* video: move display and timing to a separate threadwm42014-08-121-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The VO is run inside its own thread. It also does most of video timing. The playloop hands the image data and a realtime timestamp to the VO, and the VO does the rest. In particular, this allows the playloop to do other things, instead of blocking for video redraw. But if anything accesses the VO during video timing, it will block. This also fixes vo_sdl.c event handling; but that is only a side-effect, since reimplementing the broken way would require more effort. Also drop --softsleep. In theory, this option helps if the kernel's sleeping mechanism is too inaccurate for video timing. In practice, I haven't ever encountered a situation where it helps, and it just burns CPU cycles. On the other hand it's probably actively harmful, because it prevents the libavcodec decoder threads from doing real work. Side note: Originally, I intended that multiple frames can be queued to the VO. But this is not done, due to problems with OSD and other certain features. OSD in particular is simply designed in a way that it can be neither timed nor copied, so you do have to render it into the video frame before you can draw the next frame. (Subtitles have no such restriction. sd_lavc was even updated to fix this.) It seems the right solution to queuing multiple VO frames is rendering on VO-backed framebuffers, like vo_vdpau.c does. This requires VO driver support, and is out of scope of this commit. As consequence, the VO has a queue size of 1. The existing video queue is just needed to compute frame duration, and will be moved out in the next commit.
* player: fix desync when seeking and switching external trackswm42014-07-291-2/+3
| | | | | | | | | | | | If you for example use --audio-file, disable the external track, seek, and enable the external track again, the playback position of the external file was off, and you would get major A/V desync. This was actually supposed to work, but broke at some time ago (probably commit 2b87415f). It didn't work, because it attempted to seek the stream if it was already selected, which was always true due to reselect_demux_streams() being called before that. Fix by putting the initial selection and the seek together.
* player: remove something DVD specificwm42014-07-221-8/+1
| | | | | This is not needed anymore, because demux_disc isolates us from this crap.
* demux: add a demuxer threadwm42014-07-161-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds a thread to the demuxer which reads packets asynchronously. It will do so until a configurable minimum packet queue size is reached. (See options.rst additions.) For now, the thread is disabled by default. There are some corner cases that have to be fixed, such as fixing cache behavior with webradios. Note that most interaction with the demuxer is still blocking, so if e.g. network dies, the player will still freeze. But this change will make it possible to remove most causes for freezing. Most of the new code in demux.c actually consists of weird caches to compensate for thread-safety issues (with the previously single-threaded design), or to avoid blocking by having to wait on the demuxer thread. Most of the changes in the player are due to the fact that we must not access the source stream directly. the demuxer thread already accesses it, and the stream stuff is not thread-safe. For timeline stuff (like ordered chapters), we enable the thread for the current segment only. We also clear its packet queue on seek, so that the remaining (unconsumed) readahead buffer doesn't waste memory. Keep in mind that insane subtitles (such as ASS typesetting muxed into mkv files) will practically disable the readahead, because the total queue size is considered when checking whether the minimum queue size was reached.
* Revert "Remove DVD and Bluray support"wm42014-07-151-0/+4
| | | | | | This reverts commit 4b93210e0c244a65ef10a566abed2ad25ecaf9a1. *shrug*
* Remove DVD and Bluray supportwm42014-07-141-4/+0
| | | | It never worked well. Just remux your DVD and BD images to mkv.
* demux: make start time a simple fieldwm42014-07-051-1/+1
| | | | Simpler, especially for later changes.
* command: change cache perentage to float, add cache-free