summaryrefslogtreecommitdiffstats
path: root/player
Commit message (Collapse)AuthorAgeFilesLines
* options: make --h list options according to a pattern passed to itwm42016-09-101-0/+1
| | | | | | Useless feature, but I want it. Won't work on Windows due to missing fnmatch().
* command: do not call mp_switch_track() before proper initializationwm42016-09-101-7/+17
| | | | | | | | | | | This is an awful corner-case party, because we've started to allow the user to send track-switching related commands before stream selection is done in the loading stage. If mp_switch_track() is called before this stream selection, it can behave inconsistently. So if we're in the pre-loading phase, we must set the stream selection options to get streams selected later, instead of calling this function. There seem to be some annoying circumstances that exclude mp_switch_track() from handling this logic too, so do it at all call-sites.
* player: fix average frame duration calculationsda89ha92016-09-091-1/+1
|
* stream, demux, config: remove some dead/unneeded option-related codewm42016-09-093-21/+1
| | | | | | | | | | 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.
* client API: fix error code stringwm42016-09-091-1/+1
| | | | Said "audio" instead of "video".
* client API: make mpv_opengl_cb_uninit_gl() behavior slightly nicerwm42016-09-092-1/+9
| | | | | | Instead of deselecting the video stream plainly, use the slightly more robust error_on_track() function. Also give it an error code (although I'm not sure if this one is confusing, it's better than the one before).
* stream_dvd, stream_dvdnav: remove weird option parsing stuffwm42016-09-081-2/+2
| | | | | | Same deal as with stream_bluray. Untested because I don't give a fuck about your shitty DVDs.
* vo: don't access global options unsynchronizedwm42016-09-081-0/+11
| | | | | And since there's no proper fine-grained option change notification mechanism yet, intercept updates to "framedrop" manually.
* atomics: readd some emulationwm42016-09-061-0/+4
| | | | | | | | | | | This time it's emulation that's supposed to work (not just dummied out). Unlike the previous emulation, no mpv code has to be disabled, and everything should work (albeit possibly a bit slowly). On the other hand, it's not possible to implement this kind of emulation without compiler support. We use GNU statement expressions and __typeof__ in this case. This code is inactive if stdatomic.h is available.
* demux: do not access global optionswm42016-09-061-5/+1
| | | | | | | | | | | | | | | | | Don't access MPOpts directly, and always use the new m_config.h functions for accessing them in a thread-safe way. The goal is eventually removing the mpv_global.opts field, and the demuxer/stream-layer specific hack that copies MPOpts to deal with thread-safety issues. This moves around a lot of options. For one, we often change the physical storage location of options to make them more localized, but these changes are not user-visible (or should not be). For shared options on the other hand it's better to do messy direct access, which is worrying as in that somehow renaming an option or changing its type would break code reading them manually, without causing a compilation error.
* audio/out: deprecate "exclusive" sub-optionswm42016-09-051-0/+3
| | | | | | | And introduce a global option which does this. Or more precisely, this deprecates the global wasapi and coreaudio options, and adds a new one that merges their functionality. (Due to the way the sub-option deprecation mechanism works, this is simpler.)
* client API: implement mpv_suspend/resume slightly differentlywm42016-09-043-6/+18
| | | | | | | | Why do these API calls even still exist? I don't know, and maybe they don't make any sense anymore. But whether they should be removed or not is not a decision I want to make now. I want to get rid of mp_dispatch_suspend/resume(), though. So implement the client APIs slightly differently.
* command: try selecting the next track if track switching failswm42016-09-031-3/+4
| | | | | | | | | | | | This affects the "cycle" command. If we switched to the next track, and it failed to initialize, we just deselected everything. Change it so that if initialization fails early (typically decoder selection), we try to continue with the track after that. (Even if nothing can be selected, the loop will terminate when trying to select nothing. Fixes #3446.
* player: remove opengl-es=no flag from opengl-hq profilewm42016-09-031-1/+0
| | | | | | | | This was mistakenly added. It was removed from the vo_opengl_hq defaults at an earlier time, but the documentation was not updated, which is why it made it back into the profile. Fixes #3485.
* config: deprecate ao and vo auto-profileswm42016-09-031-0/+2
| | | | | | | | | These never made any sense. They checked the --vo/--ao option, and applied the profile corresponding to the first entry. So the only way to get any use of those was to use the --ao or --vo option explicitly. You can get the same functionality by making a manual profile, making these force the ao/vo, and then using --profile on command line instead of --vo/--ao.
* command: remove vo-cmdlinewm42016-09-021-13/+0
| | | | | | With the recent vo_opengl changes it doesn't do anything anymore. I don't think a deprecation period is necessary, because the command was always marked as experimental.
* vo_opengl: deprecate sub-options, add them as global optionswm42016-09-022-0/+36
| | | | | | | | | | | | | | | | | | | | | | | | vo_opengl sub-option were always rather annoying to handle. It seems better to make them global options instead. This is simpler and easier to use. The only disadvantage we are aware of is that it's not clear that many/all of these new global options work with vo_opengl only. --vo=opengl-hq is also deprecated. There is extensive compatibility with the old behavior. One exception is that --vo-defaults will not apply to opengl-hq (though with opengl it still works). vo-cmdline is also dysfunctional and will be removed in a following commit. These changes also affect opengl-cb. The update mechanism is still rather inefficient: it requires syncing with the VO after each option change, rather than batching updates. There's also no granularity (video.c just updates "everything", and if auto-ICC profiles are enabled, vo_opengl.c will fetch them on each update). Most of the manpage changes were done by Niklas Haas <git@haasn.xyz>.
* m_config: introduce basic mechanism to synchronize global option updateswm42016-09-022-0/+2
| | | | | | | | | | | | | | | | | | 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.
* command: deprecate "cache" property, replace with "cache-percent"wm42016-09-021-2/+4
| | | | | | The --cache option and cache property conflict, so one of them has to be renamed. The option is probably used frequently, so initiate deprecation/rename of the property.
* client API: create core thread at an earlier timewm42016-09-012-54/+47
| | | | | | | | | | | | | Create the core thread right in mpv_create(), and reduce what mpv_initialize() does further. This is simpler, and allows the API user to do more before calling mpv_initialize(). The latter is not the real goal, rather we'd like mpv_intialize() reduced to do almost nothing. It still does a lot, but nothing truly special anymore that is absolutely required for basic mpv workings. One thing we want the user to be able to do is changing properties before mpv_initialize() to reduce the special status of mpv_set_option().
* command: fix or document some property/option consistency issueswm42016-09-012-20/+17
| | | | | | | | | | | | | Make some existing properties behave more like options. This mostly means they don't deny access if the associated component is not active, but redirects to the option. One kind of fishy change is that we apply --brightness etc. only if they're not set to the default value. This won't necessarily work with --vo=xv, but affects only cases where 1. the Xv adapter has been changed to non-defaults, and 2. the user tries to reset them with mpv by passing e.g. --brightness=0. We don't care about Xv, and the noted use-case is dumb, so this change is acceptable.
* command: remove 2 deprecated propertieswm42016-09-011-50/+0
| | | | | They were delcared to be removed in mpv 0.20.0, and the next release will be 0.21.0.
* command: rename/deprecate some conflicting property nameswm42016-09-011-3/+7
| | | | | | These conflict with options of the same name, and prevent a "full" unification. Not addressed is the "cache" property, and possibly a few properties that behave differently from their equivalent options.
* command: add options to property listwm42016-09-014-40/+101
| | | | | | | | | | | Now options are accessible through the property list as well, which unifies them to a degree. Not all options support runtime changes (meaning affected components need to be restarted for the options to take effects). Remove from the manpage those properties which are cleanly mapped to options anyway. From the user-perspective they're just options available through the property interface.
* vo: change messy handling of fullscreen and other flagswm42016-08-301-10/+5
| | | | | | | | | | | | | | Before this commit, all VOs had to toggle the option flag themselves, now command.c does it. I can't really comprehend why it required every VO to do this manually. Maybe it was for rejecting the property/option change if the VO didn't support a specific capability. But then it could have checked the VOCTRL result. In any case, I don't care, and successfully changing the property without doing anything (With some VOs) is fine too. Many things work this way now, and it's simpler overall. This change will be useful for cleaning up VO option handling.
* options: make mp_vo_opts options an actual sub-option groupwm42016-08-304-12/+12
| | | | | | | | | | | 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.)
* command: cosmetics: fix some minor whitespace mistakeswm42016-08-301-2/+2
|
* player: make --force-window work with opengl-cbwm42016-08-301-0/+1
| | | | | No reason not to? This probably avoids surprises if someone really tries to combine them.
* player: slightly adjust framerate guessing heuristicwm42016-08-291-6/+8
| | | | | | | | | | | | | | | | | | | | | | Some files not only use rounded timestamps, but they also do it incorrectly. They may jitter between up to 4 specific frame durations. In this case, I found a file that mostly used 41ms and 42ms, but also had 40ms and 43ms outliers (often but not always following each other). This breaks the assumption of the framerate estimation code that the frame duration can deviate up to 1ms. If it jitters around 4 possible frame durations, the maximum deviation is 3ms. Increase it accordingly. The change might make playback of "true VFR" video via display-sync mode worse, but it's not like it was particularly good in the first place. Also, the check whether to usen the container FPS needs to be stricter. In the worst case, num_dur is 1, which doesn't really indicate any evidence that the framerate is correct. Only if there are "enough" frames the deviation check will become meaningful. 16 is an arbitrary value that has been designated "enough" by myself. Also otuput the frame duration values for --dump-stats.
* command: export profile list as a propertywm42016-08-281-0/+17
| | | | | | | Targeted at scripts, which can do whatever they want with it. This comes with the promise that they could get randomly broken any time. See #977.
* player: add option to disable video OSDwm42016-08-281-4/+9
| | | | | | | | | | | | | | Normally, OSD can be disabled with --osd-level=0. But this also disables terminal OSD, and some users want _only_ the terminal OSD. Add --video-osd=no, which essentially disables the video OSD. Ideally, it should probably be possible to control terminal and video OSD levels independently, but that would require separate OSD timers (and other state) for both components, so don't do it. But because the current situation isn't too ideal, add a threat to the manpage that might be changed in the future. Fixes #3387.
* command: add property for current subtitle textwm42016-08-271-1/+21
| | | | Requested by someone. Reuses the code for terminal subtitle display.
* player: fix minor spelling mistake in osc.luaJames Cowgill2016-08-271-1/+1
| | | | | Lintain (https://lintian.debian.org/) complains about this particular spelling mistake.
* player: avoid some redundant terminal status updateswm42016-08-261-11/+9
| | | | | Run term_osd_update() just once per update, instead of twice (once for the status line, and once for the terminal OSD messafe).
* player: don't directly access demuxer->streamwm42016-08-262-6/+4
| | | | | | | | | | Cleaner and makes it easier to change the underlying stream. mp_property_stream_capture() still directly accesses it directly via demux_run_on_thread(). This is evil, but still somewhat sane and is not getting into the way here. Not sure if I got all field accesses.
* audio: avoid missed wakeups with ab-loopswm42016-08-241-1/+5
| | | | Could get "stuck".
* audio: do not apply --audio-channels if spdif passthrough is in usewm42016-08-221-5/+9
| | | | | | | | If spdif is enabled, the channel layout has no meaning other than setting the number of channels. The number of channels must be fixed to achieve the exact bitrate required. Fixes #3445.
* player: log if video is considered an imagewm42016-08-211-0/+1
| | | | It's a heristic that can fail, so better log it.
* 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.
* command: prevent O(n^2) behaviour for playlist propertyJames Ross-Gowan2016-08-201-3/+25
| | | | | | | | | When fetching the playlist property, playlist_entry_from_index would be called for each playlist entry, which traversed a linked list to get the entry corresponding to the specified index. This was very slow for large playlists. Since get_playlist_entry is called for each index in order, it can avoid a full traversal of the linked list by using the next pointer on the previously requested entry.
* player: refresh very low framerate video on filter changeswm42016-08-191-1/+3
| | | | | | | Limit the max. time the refresh is delayed. Make it refresh at all if image mode is enabled. Fixes #3435.
* vf_rotate: allow arbitrary rotationwm42016-08-191-2/+2
| | | | | | | vf_rotate selects the correct filter for 90° rotation, but it can be extended to use lavfi's vf_rotate as fallback. See #3434.
* player: make looping slightly more seamlesswm42016-08-185-42/+38
| | | | | | 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.
* audio: improve aspects of EOF handlingwm42016-08-181-19/+40
| | | | | | | | | | | The code actually kept going out of EOF mode into resync mode back into EOF mode when the playloop had to wait after an audio EOF caused by the endpts. This would break seamless looping (as added by the next commit). Apply endpts earlier, to ensure the filter_audio() function always returns AD_EOF in this case. The idiotic ao_buffer makes this an amazing pain in the ass.
* video: don't discard video frames after endptswm42016-08-181-3/+5
| | | | | | | | | | | | Instead of letting it keep decoding by trying to find a new frame, "plug" the frame queue by not removing it. (Or actually, by putting it back instead of discarding it.) Matters for seamless looping (following commits), and possibly some other corner cases. The added function vf_unread_output_frame() is a bit of a sin, but still reasonable, since its implementation is trivial.
* player: add option to control duration of image displaywm42016-08-171-12/+22
| | | | | | | | | | | | | The --image-display-duration option controls how long an image is displayed. It's also possible to display the image forever (until manual user interaction stops playback). With this, the core drops the old method to "drain" video (i.e. waiting for the last frame duration on end of playback). Instead, we reuse MPContext.time_frame. The old mechanism was disabled for non-images anyway. Fixes #3425.
* player: allow passing flags to queue_seek()wm42016-08-156-24/+31
| | | | | | | | | | | | Change the last parameter from a bool to an int, which is supposed to take bit-flags. The at this point only flag is MPSEEK_FLAG_DELAY, which replaces the previous bool parameter. The old false parameter becomes 0, the old true parameter becomes MPSEEK_FLAG_DELAY. Since the old "immediate" parameter is now essentially inverted, two coalesced immediate and delayed seeks end up as delayed instead of immediate. This change doesn't matter, since there are no relative immediate seeks anyway.
* command: add replaygain information properties to track-listwm42016-08-131-0/+12
|
* command: add a property that returns filename without extensionwm42016-08-111-1/+13
| | | | Requested. Fixes #3404.
* player: add --no-autoload-files optionwm42016-08-101-0/+6
| | | | Allt his auto-loading is getting annoying especially for testing.
* player: add --audio-wait-open optionswm42016-08-092-0/+10
| | | | Complements the option added in the previous commit.
* player: add --audio-stream-silencewm42016-08-091-0/+3
| | | | | Completely insane that this has to be done. Crap for compensating HDMI crap.
* client API: add stream_cb API for user-defined stream implementationsAman Gupta2016-08-072-0/+65
| | | | | | Based on #2630. Some heavy changes by committer. Signed-off-by: wm4 <wm4@nowhere>
* client API: add MPV_ERROR_GENERICwm42016-08-071-0/+1
| | | | Because why not.
* player: gross hack to improve non-hr seeking with external audio trackswm42016-08-073-0/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Relative seeks backwards with external audio tracks does not always work well: it tends to happen that video seek back further than audio, so audio will remain silent until the audio's after-seek position is reached. This happens because we strictly seek both video and audio demuxer to the approximate desirted target PTS, and then start decoding from that. Commit 81358380 removes an older method that was supposed to deal with this. It was sort of bad, because it could lead to the playback core freezing by waiting on network. Ideally, the demuxer layer would probably somehow deal with such seeks, and do them in a way the audio is seeked after video. Currently this is infeasible, because the demuxer layer assumes a single demuxer, and external tracks simply use separate demuxer layers. (MPlayer actually had a pseudo-demuxer that joined external tracks into a single demuxer, but this is not flexible enough - and also, the demuxer layer as it currently exists can't deal with dynamically removing external tracks either. Maybe some time in the future.) Instead, add a gross hack, that essentially reseeks the audio if it detects that it's too far off. The result is actually not too bad, because we can reuse the mechanism that is used for instant track switching. This way we can make sure of the right position, without having to care about certain other issues. It should be noted that if the audio demuxer is used for other tracks too, and the demuxer does not support refresh seeking, audio