summaryrefslogtreecommitdiffstats
path: root/player
Commit message (Collapse)AuthorAgeFilesLines
* client API: add mpv_load_config_file()wm42014-05-181-0/+15
| | | | | | | This is probably a good idea, because it would make it easier for software embedding mpv to configure the mpv parts, without requiring the host program to provide explicit mechanisms for this (other than calling mpv_load_config_file()).
* options: unify code for setting string and "raw" optionswm42014-05-182-47/+44
| | | | | | | | | The code paths for setting options by string and by direct "raw" value were too different, which resulted in some weird code. Make the code paths closer to each other. Also, use this to remove the weirdness in the mpv_set_option() implementation.
* threads: use mpv time for mpthread_cond_timedwait wrapperwm42014-05-181-2/+2
| | | | | | Use the time as returned by mp_time_us() for mpthread_cond_timedwait(), instead of calculating the struct timespec value based on a timeout. This (probably) makes it easier to wait for a specific deadline.
* player: increase seek accuracy when refreshing display on filter changewm42014-05-181-1/+1
| | | | | | | | | When the player is paused, and video filters are changed, an exact seek is executed to refresh the display. Increase the exactness of the seek in this case; this reuses the code used for frame backstepping. It might help in cases where seeking is very imprecise, such as with transport streams.
* command: add a disc-menu-active propertywm42014-05-183-0/+30
| | | | Returns whether a DVD/BD menu is active. As requested by #788.
* client API: fix "missed" property notificationswm42014-05-181-19/+25
| | | | | | | | | | | | | | | | | | If a property is notified as changed, and then again (before the change notification is returned to the client), and the second change is a sporadic change (i.e. nothing actually changed) and the change notification was associated with with a data type, it could happen that a change was "overlooked", because it would detect no change on the second notification. This is actually a pretty annoying corner case, due to the annoying way we do things, so just store both the previously returned _and_ the newly obtained property value. then we always compare with the user value to check for a change, excluding any possibility of a missed change. Note that we don't (can't/shouldn't) care if a value changes, and then changes back; it's fine if that doesn't generate a notification. This is due to how property notifications are supposed to be coalesced.
* x11: replace--[x11-]fstype option with --x11-netwmwm42014-05-161-11/+0
| | | | | Simplifies the code a lot. You can still use --x11-netwm=no to disable NetWM for whatever reasons.
* player: reorganize how lua scripts are loadedwm42014-05-138-130/+205
| | | | | | Make loading of scripts independent of Lua. Move some of the loading code from lua.c to scripting.c, and make it easier to add new scripting backends.
* player: disable hr-seek framedropping during backsteppingwm42014-05-121-2/+3
|
* player: don't assign "false" to pointerwm42014-05-111-1/+1
| | | | | | | This is legal in theory. "false" expand to 0, and 0 is a valid pointer value. But I guess this was not really intended. Found by cppcheck.
* input: remove pausing command prefixeswm42014-05-111-9/+0
| | | | | | These are now equivalent to combining commands with the "cycle pause" or "set pause" commands, and thus are not needed anymore. They were also obscure and undocumented.
* player: don't complain on too long filenameswm42014-05-101-2/+2
| | | | | | | | | mpv supports per-file config files, basically filename+".conf". We use a static buffer for the new filename, and if that buffer is too small, we print a warning. This is confusing for e.g. long URLs, so just hide the warning by default. Why not dynamically allocate the buffer? Who cares.
* command: add property that estimates current video FPSwm42014-05-081-0/+27
| | | | | | | | | | | | | | | | | | This is done after filters, so things like framerate-doubling deinterlacing is accounted for. Unfortunately, framedropping can cause inaccuracies (especially after precise seeks), and we can't really know when that happens. Even though we know that the decoder might drop a frame if we request it to do so, we don't know when the dropped frame will start or stop affecting the video filter chain. Video filters can have frames buffered, and we can't tell at which point the dropped frame would have been output. It's not even possible to mark a discontinuity after seek, because again we don't know if the filter chain still has the discontinuity within its buffers. So we have to live with the fact that the output of this property can be completely broken after seek, unless --no-hr-seek-framedrop is used.
* options: add --hr-seek-framedrop optionwm42014-05-071-1/+2
| | | | | | | | This allows disabling of decoder framedrop during hr-seek. It's basically another useless option, but it will help exploring whether this framedropping really makes seeking faster, or whether disabling it helps with precise seeking (especially frame backstepping).
* player: avoid reconfig during seekingwm42014-05-071-1/+2
| | | | | This probably matters only in extremely corner-case heavy testcases, such as using mf:// with a bunch of differently sized images.
* player: remove VO from seeking code pathwm42014-05-072-11/+26
| | | | | | | | | | | | | | | Until recently, the VO was an unavoidable part of the seeking code path. This was because vdpau deinterlacing could double the framerate, and hr- seek and framestepping etc. all had to "see" the additional frames. But we've removed the frame doubling from the vdpau VO and moved it into a video filter (vf_vdpaupp), and there's no reason left why the VO should participate in seeking. Instead of queuing frames to the VO during seek and skipping them afterwards, drop the frames early. This actually might make seeking with vo_vdpau and software decoding faster, although I haven't measured it.
* player: minor reshuffling of video codewm42014-05-071-28/+30
|
* player: limit max. fallback frame durationwm42014-05-071-1/+1
| | | | | | It's calculated from the demuxer reported FPS, which is not very reliable. Limit the damage a completely insane and broken value could cause.
* player: handle video reconfig slightly different againwm42014-05-072-23/+29
| | | | | | | | | | Now we avoid calling update_video() twice on reconfig (once to check whether there are still new frames, and again to actually do the reconfig). Instead, we check whether there's still something going on before calling update_video() at all, and depending on that update_video() will be allowed to reconfig or not. This will simplify some things later.
* player: reset last_frame_duration on initwm42014-05-071-0/+1
|
* command: rename stream-length to file-size, format file sizeAndrey Morozov2014-05-061-13/+44
| | | | Signed-off-by: wm4 <wm4@nowhere>
* command: remove ifdefs for deint filterswm42014-05-061-4/+0
| | | | Doesn't have much of a purpose.
* common: change mp_snprintf_append semanticswm42014-05-051-2/+2
| | | | | | | | Make it more suitable for chaining. This means a function formatting a value to a string using a static buffer can work exactly like mp_snprintf_append itself. Also rename it to mp_snprintf_cat, because that's shorter.
* options: merge ---sub-auto-match with --sub-autowm42014-05-041-1/+1
| | | | There's no reason why these should be separate.
* options: remove deprecated --identifyMartin Herkt2014-05-042-29/+0
| | | | | | | Also remove MSGL_SMODE and friends. Note: The indent in options.rst was added to work around a bug in ReportLab that causes the PDF manual build to fail.
* options: rename video-related options/propertiesMartin Herkt2014-05-041-1/+1
| | | | | | | | | | | Renamed options: --aspect → --video-aspect --fstype → --x11-fstype --native-fs → --fs-missioncontrol --name → --x11-name Renamed properties: aspect → video-aspect
* options: rename audio-related options/propertiesMartin Herkt2014-05-041-2/+2
| | | | | | | | | | | | | Renamed options: --audiofile → --audio-file --audiofile-cache → --audio-file-cache --channels → --audio-channels --format → --audio-format --srate → --audio-samplerate Renamed properties: samplerate → audio-samplerate channels → audio-channels
* options: rename subtitle-related optionsMartin Herkt2014-05-041-1/+1
| | | | | | | | | --ass → --sub-ass --autosub → --sub-auto --autosub-match → --sub-auto-match --sub → --sub-file --subcp → --sub-codepage --subfps → --sub-fps
* video: remove a corner case by introducing another onewm42014-05-031-3/+2
| | | | | | | | | | | | | | | | | | | | When loading a video, and a script reacts to MPV_EVENT_VIDEO_RECONFIG, and the script inserts a video filter, the first frame can be skipped. This happens simply because the first frame is (usually) still queued in the video filter chain, and changing the filter chain will drop all queued frames. So this is just a corner case that just happens in a weird situation. But it's still annoying when having such a script, and starting something where the first frame is very visible, and not starting in paused mode. (All in all, a corner case.) Do this by immediately queuing 1 filtered frame to the VO immediately after reconfig, instead of leaving it to the video loop doing it as "incremental" work. Simply fallthrough to the next case. We must not overwrite "r" in this case, because that contains the current status. Note that the first frame will not be filtered using the inserted filter.
* video: fix video end conditionwm42014-05-031-5/+4
| | | | | | | | | | This wasn't really fine, and could (perhaps) cause weird corner cases on reinit or when the player was paused. Before eb9d20, video_left was also set to true if vo->frame_loaded was set, and this variable basically indicated whether the previous update_video() call was successful. This was overlooked when changing everything. Simply always call update_video(), it should be equivalent.
* video: rename a variablewm42014-05-031-2/+2
| | | | Cosmetic change, reduce the diff of the following commit.
* client API: fix inverted conditionwm42014-05-021-1/+1
| | | | Oops. Sigh.
* video: removed unused stuffwm42014-05-021-1/+0
|
* player: remove extremely obscure undefined behaviorwm42014-05-021-1/+2
| | | | | | Apparently the value of a pointer is "indeterminate" after a free() call, even if you never dereference the pointer after the free. Since talloc_free() calls free(), this applies here.
* client API, video: signal reconfig at the right timewm42014-05-021-4/+2
| | | | Filter reconfig can now happen a few frames before VO reconfig.
* lua: remove "lua/" prefix from script nameswm42014-05-021-1/+1
| | | | | | | | | This affects the return value of mp.script_name, the "client name" (what's returned by mpv_client_name()) and all associated features, as well as the mpv terminal output module prefix when scripts print something. As discussed in #748.
* video: change everythingwm42014-05-023-180/+224
| | | | | | | Change how the video decoding loop works. The structure should now be a bit easier to follow. The interactions on format changes are (probably) simpler. This also aligns the decoding loop with future planned changes, such as moving various things to separate threads.
* video: handle colorspace and aspect overrides separatelywm42014-05-023-5/+5
| | | | | Now the video filter code handles these explicitly, which should increase robustness (or at least find bugs earlier).
* command, vo_vdpau: respect vdpau deint sub-optionwm42014-05-021-2/+15
| | | | | This is a horrible hack to keep compatibility with the vo_vdpau deint sub-option.
* command: redo deinterlace filter probingwm42014-05-021-18/+27
| | | | | | | Give up on the deint_filters[] array, and probe using explicit code instead. Add additional checks to test the pixel format to avoid annoying warnings when a hardware deinterlacer is inserted when the current video chain is obviously incompatible.
* command: make enabling deinterlacing with vdpau workwm42014-05-021-0/+3
| | | | | | This restores the capability of enabling deinterlacing with the 'cycle deinterlace' command with vo_vdpau, and also makes it work with vo_opengl.
* video: improve error messageswm42014-04-301-2/+1
|
* vf-metadata: fix handling of NULL metadataKevin Mitchell2014-04-291-11/+16
| | | | | | lavfi would segfault due to a NULL dereference if it was asked for its metadata and none had been allocated (oops). This happens for libav which has no concept of filter metadata.
* video: remove redundant mp_image display_w/_h memberswm42014-04-291-4/+1
| | | | | | | | | | | | | | | | | Commit 5e4e248 added a mp_image_params field to mp_image, and moved many parameters to that struct. display_w/h was left redundant with mp_image_params.d_w/d_h. These fields were supposed to be always in sync, but it seems some code forgot to do this correctly, such as vf_fix_img_params() or mp_image_copy_attributes(). This led to the problem in github issue #756, because display_w/_h could become incorrect. It turns out that most code didn't use the old fields anyway. Just remove them. Note that mp_image_params.d_w/d_h are supposed to be always valid, so the additional checks for 0 shouldn't be needed. Remove these checks as well. Fixes #756.
* video: don't drop last frame when deinterlacing with yadifwm42014-04-281-5/+7
| | | | | | | | | | | | | | | | | | Or in other words, add support for properly draining remaining frames from video filters. vf_yadif is buffering at least one frame, and the buffered frame was not retrieved on EOF. For most filters, ignore this for now, and just adjust them to the changed semantics of filter_ext. But for vf_lavfi (used by vf_yadif), real support is implemented. libavfilter handles this simply by passing a NULL frame to av_buffersrc_add_frame(), so we just have to make mp_to_av() handle NULL arguments. In load_next_vo_frame(), we first try to output a frame buffered in the VO, then the filter, and then (if EOF is reached and there's still no new frame) the VO again, with draining enabled. I guess this was implemented slightly incorrectly before, because the filter chain still could have had remaining output frames.
* client API: add chapter change eventwm42014-04-276-0/+17
| | | | Also works for mpv_observe_property() on the "chapter" property.
* stream: make mp_input_check_interrupt thread-safewm42014-04-251-0/+1
| | | | | | | | | | | | | | | | The interrupt callback will can be called from another thread if the cache is enabled, and the stream disconnects. Then stream_reconnect() will call this function from within the cache thread. mp_input_check_interrupt() is not thread-safe due to read_events() not being thread-safe. It will call input callbacks added with mp_input_add_fd() - these callbacks lead to code not protected by locks, such as reading X11 events. Solve this by adding a stupid hack, which checks whether the calling thread is the main playback thread (i.e. calling the input callbacks will be safe). We can remove this hack later, but it requires at least moving the VO to its own thread first.
* stream: remove interrupt callback global variableswm42014-04-251-1/+8
| | | | | | | | | | | | This used global variables for the asynchronous interrupt callback. Pick the simple and dumb solution and stuff the callback into mpv_global. Do this because interrupt checking should also work in the connect phase, and currently stream creation equates connecting. Ideally, this would be passed to the stream on creation instead, or connecting would be separated from creation. But since I don't know yet which is better, and since moving stream/demuxer into their own thread is something that will happen later, go with the mpv_global solution.
* lua: fix stack going out of syncwm42014-04-241-0/+1
| | | | This broke with recursive tables.
* dispatch: move into its own source filewm42014-04-233-2/+3
| | | | | | | This was part of osdep/threads.c out of laziness. But it doesn't contain anything OS dependent. Note that the rest of threads.c actually isn't all that OS dependent either (just some minor ifdeffery to work around the lack of clock_gettime() on OSX).
* video: add a "hwdec" property to enable or disable hw decoding at runtimewm42014-04-231-0/+33
|
* client API: make mpv_set_option set options nativelywm42014-04-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | This should fix some issues, such as not being able to set the "no-video" option with MPV_FORMAT_FLAG. Note that this changes semantics a bit. Now setting an option strictly overwrite it, even if the corresponding command line option does not. For example, if we change --sub to append by default, then setting the "sub" option via the client API would still never append. (Oddly, this also applies to --vf-add, which will overwrite the old value when using the client API.) I'm doing this because there's no proper separation between the command line parser and setting an option using the MPV_FORMAT_STRING format. Maybe the solution to this mess would be adding format aware code (i.e. m_option_set_node) to every option type, and falling back to strings only if needed - but this would mean that you couldn't set e.g. an integer option using MPV_FORMAT_STRING, which doesn't seem to be ideal either. In conclusion, the current approach seems to be most robust, but I'm open to suggestions should someone find that these semantics are a problem.
* command: export rotation parameterwm42014-04-221-0/+1
| | | | For completeness.
* video: auto-insert software rotation filterwm42014-04-211-5/+44
| | | | | | | If the VO can't do rotation, insert a filter to do this. Note that this doesn't reuse the filter insertion code from command.c (used by "vf" input command), because that would end up more complicated: we don't even want to change the user filter option.
* encode: don't resume playback when encodingwm42014-04-191-0/+1
| | | | | The previous commit doesn't handle additionally loaded config files, such as the playback resume mechanism.
* encode: don't apply default config optionswm42014-04-192-5/+18
| | | | | | | | | | | | Often, user configs set options that are not suitable for encoding. Usually, playback and encoding are pretty different things, so it makes sense to keep them strictly separate. There are several possible solutions. The approach taken by this commit is to basically ignore the default config settings, and switch to an [encoding] config profile section instead. This also makes it impossible to have --o in a config file, because --o enables encode mode. See github issue #727 for discussion.
* Remove CPU detection and inline asm handlingwm42014-04-191-2/+0
| | | | | | | | | | | | | | Not needed anymore. I'm not opposed to having asm, but inline asm is too much of a pain, and it was planned long ago to eventually get rid fo all inline asm uses. For the note, the inline asm use that was removed with the previous commits was almost worthless. It was confined to video filters, and most video filtering is now done with libavfilter. Some mpv filters (like vf_pullup) actually redirect to libavfilter if possible. If asm is added in the future, it should happen in the form of external files.
* encode: disable keep-open when encodingJames Ross-Gowan2014-04-191-0/+1
|
* player: fix audio EOF check on --no-audiowm42014-04-181-1/+1
| | | | | This considered audio to never reach EOF when audio was disabled, instead of always being EOF.
* player: add a --loop-file optionwm42014-04-172-0/+12
| | | | Unlike --loop, loops a file instead of the playlist.
* player: unrangle one aspect of audio EOF handlingwm42014-04-171-9/+4
| | | | | | | | | | | | | | | | | | For some reason, the buffered_audio variable was used to "cache" the ao_get_delay() result. But I can't really see any reason why this should be done, and it just seems to complicate everything. One reason might be that the value should be checked only if the AO buffers have been recently filled (as otherwise the delay could go low and trigger an accidental EOF condition), but this didn't work anyway, since buffered_audio is set from ao_get_delay() anyway at a later point if it was unset. And in both cases, the value is used _after_ filling the audio buffers anyway. Simplify it. Also, move the audio EOF condition to a separate function. (Note that ao_eof_reached() probably could/should whether the last ao_play() call had AOPLAY_FINAL_CHUNK set to avoid accidental EOF on underflows, but for now let's keep the code equivalent.)
* audio: explicitly document audio EOF conditionwm42014-04-171-1/+1