summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* command: make sub-add and audio-add commands asyncwm42018-05-244-7/+24
| | | | | | | | | | Pretty trivial, since commands can be async now, and the common code even provides convenience like running commands on a worker thread. The only ugly thing is that mp_add_external_file() needs an extra flag for locking. This is because there's still some code which calls this synchronously from the main thread, and unlocking the core makes no sense there.
* command: add infrastructure for async commandswm42018-05-2410-47/+329
| | | | | | | | | | | | | | | | | | | | | | | | | | | This enables two types of command behavior: 1. Plain async behavior, like "loadfile" not completing until the file is fully loaded. 2. Running parts of the command on worker threads, e.g. for I/O, such as "sub-add" doing network accesses on a thread while the core continues. Both have no implementation yet, and most new code is actually inactive. The plan is to implement a number of useful cases in the following commits. The most tricky part is handling internal keybindings (input.conf) and the multi-command feature (concatenating commands with ";"). It requires a bunch of roundabout code to make it do the expected thing in combination with async commands. There is the question how commands should be handled that come in at a higher rate than what can be handled by the core. Currently, it will simply queue up input.conf commands as long as memory lasts. The client API is limited by the size of the reply queue per client. For commands which require a worker thread, the thread pool is limited to 30 threads, and then will queue up work in memory. The number is completely arbitrary.
* thread_pool: make it slightly less dumbwm42018-05-243-43/+142
| | | | | | | | | | | | The existing thread pool code is the most primitive thread pool possible. That's fine, but one annoying thing was that it used a static number of threads. Make it dynamic, so we don't need to "waste" idle threads. This tries to add threads as needed. If threads are idle for some time, destroy them again until a minimum number of threads is reached. Also change the license to ISC.
* client: merge can_terminate() functionwm42018-05-241-15/+12
| | | | | | | | | | | This has some tricky interactions. In particular, it requires the core to be locked due to reading outstanding_async, which is documented on the only caller only. It's probably better to merge it with its only caller. The new code should be strictly equivalent, other than the fact that it doesn't temporarily unlock+lock when entering the loop for the first time (which doesn't matter here).
* misc: add a synchronization helperwm42018-05-243-0/+102
| | | | | | | | | | | | | | | | | This is almost like rendezvous(), except it allows async wakeup, and does not require global state. It will be used by a later commit. struct mp_waiter is intended to be allocated on the stack, and uses an initializer including PTHREAD_MUTEX_INITIALIZER. This is the first case in mpv that it uses PTHREAD_MUTEX_INITIALIZER for stack-allocated mutexes. It seems POSIX still does not allow this formally, but since POSIX is worth less than used toilet paper, I don't really care. Modern OSes use futexes, which means you can make _every_ memory location a lock, and this code tries to make use of it, without using OS specific code. The name of the source file is rather generic, because I intend to dump further small helpers there (or maybe move mp_rendezvous() to it).
* input: move an enum back to its correct placewm42018-05-242-13/+13
| | | | This was accidentally moved together with the cmd stuff.
* command: handle list commands like normal commandswm42018-05-242-11/+11
| | | | Pretty annoying.
* dispatch: add an assert()wm42018-05-241-0/+1
|
* client API: some doxygen fixes/additionswm42018-05-243-6/+28
|
* demux, player: fix playback of sparse video streams (w/ still images)Aman Gupta2018-05-246-5/+36
| | | | | | | | | | | | | | | Fixes several issues playing back mpegts with video streams marked as having "still images". For example, see this video which has frames only every 6s: https://s3.amazonaws.com/tmm1/music-choice.ts Changes include: - start playback right away, without waiting for first video frame - do not consider the sparse video stream in demuxer underrun detection - do not require multiple video frames for the VO - use audio as the master stream for demuxer metadata events - use audio stream for playback time Signed-off-by: Aman Gupta <aman@tmm1.net>
* demux_lavf: co-locate disposition checksAman Gupta2018-05-241-2/+2
| | | | Signed-off-by: Aman Gupta <aman@tmm1.net>
* waf: require wayland-protocols >= 1.14Rostislav Pehlivanov2018-05-201-1/+1
| | | | Needed for the new xdg-wm tiling enums.
* wayland_common: require wl_compositor of version 3Rostislav Pehlivanov2018-05-201-3/+2
| | | | | We already did require it, in order to call set_buffer_scale. This just makes it error out more gracefully.
* wayland_common: fix maximized stateRostislav Pehlivanov2018-05-202-13/+22
| | | | Window size should not change if the window has been maximized or tiled.
* vo_gpu: allow higher icc-contrast and improve loggingNiklas Haas2018-05-172-3/+4
| | | | | | | | | | With the advent of actual HDR devices, my real measured ICC profile has an "infinite" contrast, since the display is completely off on pure black inputs. 100k:1 might not be enough, so let's just bump it up to 1m:1 to be safe. Also, improve the logging in the case that the detected contrast is too high by default.
* stats: show sample format of audio tracksfan52018-05-171-0/+1
|
* waftools: update clang_compilation_databaseBin Jin2018-05-171-13/+33
| | | | | The old copy is broken with waf-1.9.8, update to the latest commit (waf-project/waf@5e4b86b81df3b9819738d757eb8d2c8646ef0ede) instead.
* manpage: fix typoNiklas Haas2018-05-171-1/+1
|
* manpage: clarify target-prim/trc=auto behaviorNiklas Haas2018-05-171-2/+6
| | | | | | | This logic has been changed throughout the years, notably in 38ac5d5 and 3bdbf6. Update the documentation to reflect the current state. Closes #5834.
* m_option: fix duplicate flag valuePhilip Sequeira2018-05-131-2/+2
|
* wscript: Remove code check for cuda hwaccelPhilip Langdale2018-05-102-17/+1
| | | | | | This was there originally to detect too-old versions of ffmpeg. We now only support >= 4.0, so it's not relevant. We just need the dependencies to be present.
* drm_atomic: Fix memory leaks in drm_atomic_createAnton Kindestam2018-05-081-34/+33
| | | | | | | | | First fix a memory leak when skipping cursor planes by inverting the check and putting everything, but the free, in the body. Then fix a missed drmModeFreePlane by simply copying the fields of the drmModePlane we are interested in and freeing the drmModePlane struct early.
* ytdl_hook: try to set video track first if availableRicardo Constantino2018-05-031-4/+4
| | | | | | | Fixes `--ytdl-format="dash-fastly_skyfire-video-363357330+dash-fastly_skyfire_sep-audio-363357330" https://vimeo.com/108650530` This happened because the video track also had audio available and after adding it expecting an audio-only track, there were no more tracks with video.
* player: add more logging around buffering stateAman Gupta2018-05-031-2/+7
|
* command: fix condition for failure when parsing cycle-value paramswm42018-05-031-1/+1
| | | | | | Could make it behave differently (and leak memory) in certain cases. Basically, m_option_parse() randomly returns 0 or 1, but most time 1, with the difference due to legacy reasons that don't matter anymore.
* command: simplify option property initwm42018-05-031-22/+13
| | | | | | | The "if (prop.name)" check is redundant, because an assert above it implies that it never can be NULL. Deduplicate some code for initializing the "prop" variable.
* input: rename weirdly named functionwm42018-05-033-4/+5
|
* input: move some more cmd definitions to cmd.hwm42018-05-032-64/+64
| | | | | | Now both command "descriptions" and runtime command instances are in cmd.h, which makes sense to me. input.h is now for the actual input context.
* input: merge cmd_list.c with cmd.cwm42018-05-037-146/+88
| | | | | | It doesn't really make sense to keep a separate cmd_list.c file, which does _not_ contain a command list, but only a few minor helper functions.
* input: rename cmd_parse.c to cmd.cwm42018-05-032-1/+1
| | | | | Done separately from the cmd.h rename to avoid issues with git being bad at tracking mixed content and filename changes.
* input: rename cmd_parse.h to cmd.hwm42018-05-035-5/+3
|
* command: split big command handler switch into separate functionswm42018-05-034-866/+1018
| | | | | | | | | | | | | | | | | | | This gets rid of run_command() and its big switch statement, which was an idiotically big function of almost 1000 lines. The switch is replaced with a callback per command, and each command is now implemented in its own function. Command IDs are not needed anymore, so the mp_command_type enum disappears. There should be no functional changes, but since this refactors 64 commands, regressions are possible. The handler() parameter is void*, because in theory the input code is supposed to be independent of the player core code. For example, you should be able to reuse the command parser code for some other part of mpv. In practice, the variable containing command list is defined in the player core anyway, so you could say this doesn't work. But I'm still trying to hold onto this idea, so I went with void*.
* input: remove some explicit uses of command IDswm42018-05-036-31/+37
| | | | | | | | | | The plan is to remove the command ID enum. This will happen by replacing the big switch statement in command.c with dispatching to per-command callbacks. As preparation, remove uses of the command IDs outside of the actual dispatching mechanism. Also remove some instances of checking cmd->def for NULL. We now require this always to be set.
* input: remove legacy command handlingwm42018-05-033-84/+0
| | | | | | | | These are old MPlayer commands that were redundant since 2007 or so. In 2013, mpv explicitly deprecated them (actually removed them, but left this wrapper, which translated them to modern commands). The list was not extended since 2013, and mpv always warned on the terminal when a legacy command was used. So it's time to remove it.
* input: move command list to command.cwm42018-05-032-215/+216
| | | | Preparation for more changes.
* encode: remove removed encode options from presetsTheAMM2018-05-031-13/+4
|
* build: make encoding mode non-optionalwm42018-05-0310-40/+9
| | | | Makes it easier to not break the build by confusing the ifdeffery.
* encode: get rid of the output packet queuewm42018-05-0313-79/+147
| | | | | | | | | | | | Until recently, ao_lavc and vo_lavc started encoding whenever the core happened to send them data. Since audio and video are not initialized at the same time, and the muxer was not necessarily opened when the first encoder started to produce data, the resulting packets were put into a queue. As soon as the muxer was opened, the queue was flushed. Change this to make the core wait with sending data until all encoders are initialized. This has the advantage that we don't need to queue up the packets.
* vo_lavc: explicitly skip redraw and repeated frameswm42018-05-032-8/+11
| | | | | | | | | | | The user won't want to have those in the video (I think). The core can sporadically issue redraws, which is what you want for actual playback, but not in encode mode. vo_lavc can explicitly detect those and skip them. It only requires switching to a more advanced internal VO API. The comments in vo.h are because vo_lavc draws to one of the images in order to render OSD. This is OK, but might come as a surprise to whoever calls draw_frame, so document it. (Current callers are OK with it.)
* video: actually wait for last frame being rendered on EOFwm42018-05-031-1/+5
| | | | | | | | | | | | | | | | | | | The video timing code could just decide that EOF was reached before it was displayed. This is not really a problem for normal playback (if you use something like --keep-open it'd show the last frame anyway, otherwise it'd at best flash it on screen before destroying the window). But in encode mode, it really matters, and makes the difference between having one frame more or less in the output file. Fix this by waiting for the VO before starting the real EOF. vo_is_ready_for_frame() is normally used to determine when the VO frame queue has enough space to send a new frame. Since the VO frame queue is currently at most 1 frame, it being signaled means the remaining frame was consumed and thus sent to the VO driver. If it returns false, it will wake up the playloop as soon as the state changes. I also considered using vo_still_displaying(), but it's not reliable, because it checks the realtime of the frame end display time.
* encode: remove old timestamp handlingwm42018-05-037-291/+57
| | | | | This effectively makes --ocopyts the default. The --ocopyts option itself is also removed, because it's redundant.
* encode: restore 2-pass modewm42018-05-031-2/+7
| | | | | | | | | | While I'm not sure whether it really works, at least it writes the pass1 log correctly now. How 2-pass stat output is supposed to interact with the new decode API is rather fishy. ffmpeg.c does the same, and before this change, the log was not written on EOF (when at least libvpx actually outputs its stats).
* manpage: -pre, -del etc. does not work on some options anymorewm42018-05-031-25/+4
| | | | | | With the internal change from stringlist to keyvaluelist, these sub-options stop working. I don't really care enough to bring them back. (Order doesn't matter, -del always seemed annoying.)
* docs/vo: fixup some minor typos a la "planed" instead of "plane"Jan Ekström2018-05-011-3/+3
|
* drm_atomic: Disallow selecting cursor planes using the optionsAnton Kindestam2018-05-011-0/+3
|
* drm_common: Be smarter when deciding on which CRTC and Encoder to useAnton Kindestam2018-05-011-1/+27
| | | | | | | | | | | | | | | | | Inspired by kmscube, first try to pick the Encoder and CRTC already associated with the selected Connector, if any. Otherwise try to find the first matching encoder & CRTC like before. The previous behavior had problems when using atomic modesetting (crtc_setup_atomic) when we picked an Encoder & CRTC that was currently being used by the fbcon together with another Encoder. drmModeSetCrtc was able to "steal" the CRTC in this case, but using atomic modesetting we do not seem to get this behavior automatically. This should also improve behavior somewhat when run on a multi screen setup with regards to deinit and VT switching (still sometimes you end up with a blank screen where you previously had a cloned display of your fbcon)
* context_drm_egl: fix some comments and log messages that had not been ↵Anton Kindestam2018-05-011-6/+5
| | | | updated since the plane rename commit
* drm/atomic: Fix crtc_setup_atomic and crtc_release_atomicAnton Kindestam2018-05-011-25/+33
| | | | | | | | | | | Add some properties which where forgotten in crtc_setup_atomic. In both change to not use DRM_MODE_PAGE_FLIP_EVENT | DRM_MODE_ATOMIC_NONBLOCK flags. This should make it more similar to the drmSetCrtc which it aims to replace (take effect directly, and blocking call). This also saves us the trouble of having to set up a poll to wait for pageflip, which would've been neccesary with DRM_MODE_PAGE_FLIP_EVENT, in both crtc_setup_atomic and crtc_release_atomic.
* drm/atomic: disable video plane when unused.LongChair2018-05-011-0/+28
| | | | | | | | | | This patch will make sure that the video plane is hidden when unused. When using high resolution modes, typically UHD, and embedding mpv, having the video plane sitting in the back when you don't play any video is eating a lot of memory bandwidth for compositing. That patch makes sure that the video layer is just disabled before and after playback.
* drm/atomic: add atomic modesetting.LongChair2018-05-011-11/+104
| | | | | | | This commit allows to add atomic modesetting when using the atomic renderer. This is actually needed when using and osd with a smaller size than screen resolution. It will also make the drm atomic path more consistent
* drm/atomic: refactor planes namesLongChair2018-05-018-55/+103
| | | | | | | | We are currently using primary / overlay planes drm objects, assuming that primary plane is osd and overlay plane is video. This commit is doing two things : - replace the primary / overlay planes members with osd and video planes member without the assumption - Add two more options to determine which one of the primary / overlay is associated to osd / video. - It will default osd to overlay and video to primary if unspecified
* drm/atomic: add connector to atomic contextLongChair2018-05-016-4/+38
| | | | | | | | | | This patch adds - DRM connector object to atomic context. - fd property to the drm atomic object as well as a method to read blob type properties. This allows to ensure that the proper connector is picked up, especially when specifying it from the commandline, and also allows to make sure we're using the right one when embedding with interop into an application.
* drm/atomic: refactor hwdec_drmprime_drm with native resourcesLongChair2018-05-018-35/+113
| | | | | | | | | | | | | | | | | That new API was introduced and allows to have several native resources. Thisuses that mechanisma for drm resources rather than the deprecated opengl-cb structs. This patch therefore add two structs that can be used with the drm atomic interop. - mpv_opengl_drm_params : which will hold all the drm handles - mpv_opengl_drm_osd_size : which will hold osd layer size This commit adds a drm-osd-size=WxH parameter to commandline which allows to define the OSD plane dimension. OSD can be upscaled to screen resolution when having OSD at video resolution is too heavy. This is especially useful for UHD modes on embedded devices where the GPU cannot handle UHD modes at a decent framerate.
* vo_gpu/video: disable compute shaders if an FBO format was not availableJan Ekström2018-05-011-0/+5
| | | | | This is actually more generic and better than just lazily plastering peak calculation together with dumb mode.
* vo_gpu/video: add improved logging when a user-specified FBO failsJan Ekström2018-05-011-2/+13
| | | | | I don't know if we can just return from this function, so for now just adding this piece of logging.
* manpage: remove 4 previously removed optionswm42018-05-011-24/+0
| | | | The manpage parts were forgotten when removing the options.
* manpage: --demuxer-seekable-cache is not experimental anymorewm42018-05-011-2/+1
| | | | | This seems to work surprisingly well, and it's enabled by default (unlike the old text claims).
* common: add missing %f time formatwm42018-05-011-0/+1
| | | | | | | | It was documented for --screenshot-template, but apparently never implemented. This value is not explicitly rounded, other than for printf() %f default formatting (which rounds to 6 digits).
* common: round all integer times to millisecondswm42018-05-011-2/+6
| | | | | | | | | This means that a time of 4.5678 is displayed as "00:00:04.568" when the format string is "%H:%M:%S.%T". Likewise, 59.99999 will be displayed as "00:01:00.000". Before this change, the sub-ms times were just truncated. Requested by TheAMM.
* cocoa: change deprecation warning from opengl-cb to libmpvAkemi2018-04-292-3/+3
|
* build: bump wayland-protocols requirement to 1.12+Jan Ekström2018-04-291-1/+1
| | | | The stable xdg-shell protocol is only available from this version.
* wayland_common: update to stable xdg-shellEmmanuel Gil Peyrot2018-04-293-52/+52
| | | | | This removes support for older compositors using the unstable version, but those will still use Xwayland by default, so not a big loss.
* gpu/video: make HDR peak computing work without work group countNiklas Haas2018-04-291-4/+5
| | | | | | | | | | Define a hard-coded value for gl_NumWorkGroups if it is not available. This adds an additional requirement of needing a shader recompile for all window size changes. This was considered a worthwhile compromise as currently f.ex. d3d11 completely lacked any peak computation - this is a major quality of life upgrade.
* gpu/video: improve HDR peak computation feature check loggingJan Ekström2018-04-291-1/+4
| | | | | Now that the feature depends on multiple features, log all of their states in the message.
* command: change cycle-value command behaviorwm42018-04-294-87/+97
| | | | | | | |