summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
* vo/x11: implement VOCTRL_GET_DISPLAY_NAMES with xrandr names (e.g., "LVDS1")Kevin Mitchell2014-11-073-2/+23
| | | | | | | | XRRGetOutputInfo contains a "name" element which corresponds to to the display names given to the user by the "xrandr" command line utility. Copy it into the xrandr_display struct for each display. On VOCTRL_GET_DISPLAY_NAMES, send a copy of the names of the displays spanned by the mpv window on.
* ipc: make sure --input-file=/dev/stdin always workswm42014-11-071-7/+20
| | | | It's not necessarily available on Unix systems other than Linux (sigh).
* vo_wayland: drop redundant "const"wm42014-11-071-1/+1
|
* vo_vaapi: fix broken error checkswm42014-11-071-2/+2
|
* ao_oss: wait for events with poll()wm42014-11-061-0/+13
| | | | | | | | | | The intention is to avoid using the timeout-based fallback. There's some minor hope that this will help with OpenBSD (see #1239), although it probably won't. Some chance that this will cause trouble with obscure OSS implementations or emulations.
* audio/out/push: when using audio wait fallback, recheck conditionwm42014-11-061-1/+2
| | | | | | | | | | | If calling ao->driver->wait() fails, we need to fallback to timeout- based waiting. But it could be that at this point, the mutex was already released (and then re-acquired). So we need to recheck the condition in order to avoid missed wakeups. This probably wasn't an actually occurring problem, but still could cause a small race-condition window if the dynamic fallback is actually used.
* sub: load .mks files as external subtitleswm42014-11-061-1/+1
|
* demux_mkv: fix indentationwm42014-11-051-3/+3
| | | | Meh.
* demux_mkv: for subtitle preroll, consider all clusterswm42014-11-051-5/+3
| | | | | | | | | This considered only index entries that were for the same track ID as the track used for seeking. This doesn't make much sense for preroll; it'll just possibly skip clusters, and select an earlier cluster. One possible negative side-effect is that the preroll might be too tight now, and miss subtitle packets more often.
* demux_mkv: apply subtitle preroll only if needed, based on cue indexwm42014-11-051-0/+16
| | | | | | | | | The demuxer has a hack to seek to the cluster before the target cluster in order to "catch" subtitle lines that start before the seek target, but overlap with the video after the seek target. Avoid this hack if the cue index indicates that there are no overlapping subtitle packets that can be caught by seeking to the previous cluster.
* demux_mkv: read CueRelativePosition/CueDuration elementswm42014-11-052-11/+29
| | | | | | | | Nothing is done with them yet. This is preparation for the following commit. CueRelativePosition isn't even saved anywhere, because I don't intend to use it. (Too messy for no gain.)
* demux_mkv: index all packetswm42014-11-051-4/+2
| | | | | | | | | | | | Instead of indexing only 1 packet per cluster (which is enough for working seeking), add every packet to the index. Since on seek, we go through every single index entry, this probably makes seeking slower. On the other hand, this code is used for files without index only (e.g. incomplete files), so it probably doesn't matter much. Preparation for the following commits.
* command: use playback time as reference for sub_seekwm42014-11-051-2/+3
| | | | | | | | | update_subtitle() already uees playback_pts to make subtitles work better in no-audio mode. Using get_current_time() usually gets playback_pts, but also has the advantage that it will use the seek target time during seeks. This will result in multiple sub_seek commands doing the right thing (at least as long as they're far enough apart so that seeking is actually initiated when the second command is run).
* demux: report 0s readahead time as fallback in some situationswm42014-11-051-1/+5
| | | | | | | | | | If no packets are queued, the readahead time is obviously 0. If the end time is smaller than the start time, the problem is probably that audio and video start at slightly different times - report 0 in this case too. Do this because seeing "???" as readahead time is a bit annoying.
* video: remove swapped-endian image format aliaseswm42014-11-055-175/+73
| | | | | Like the previous commit, this removes names only, not actual support for these formats.
* vo_wayland: don't use endian-specific defineswm42014-11-051-18/+22
| | | | | | | | | | | | Instead, use the native-endian alias, and switch the wayland format depending on the target platform's endian. This drops support for swapped-endian formats, but I think that is ok. Not only are the affected formats rather ancient and backwards, but using swapped formats probably does not make any sense for performance either. Untested.
* video: remove aliases for some rarely referenced image formatswm42014-11-052-82/+0
| | | | | | | | | These formats are still supported; you just can't reference them via a defined constants directly. They are now handled via the generic passthrough. (If you want to use such a format, you either have to add the entry back, or use AV_PIX_FMT_* directly.)
* video: add image format test programwm42014-11-051-0/+63
|
* video: passthrough unknown AVPixelFormatswm42014-11-053-1/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a rather radical change: instead of maintaining a whitelist of FFmpeg formats we support, we automatically support all formats. In general, a format which doesn't have an explicit IMGFMT_* name will be converted to a known format through libswscale, or will be handled by code which can treat pixel formats in a generic way using the pixel format description, like vo_opengl. AV_PIX_FMT_UYYVYY411 is a special-case. It's packed YUV with chroma subsampling by 4 in both directions. Its component order is documented as "Cb Y0 Y1 Cr Y2 Y3", meaning there's one UV sample for 4 Y samples. This means each pixel uses 1.5 bytes (4 pixels have 1 UV sample, so 4 bytes + 2 bytes). FFmpeg can actually handle this format with its generic mechanism in an extremely awkward way, but it doesn't work for us. Blacklist it, and hope no similar formats will be added in the future. Currently, the AV_PIX_FMT_*s allowed are limited to a numeric value of 500. More is not allowed, and there are some fixed size arrays that need to contain any possible format (look for IMGFMT_END dependencies). We could have this simpler by replacing IMGFMT_* with AV_PIX_FMT_* through the whole codebase. But for now, this is better, because we can compensate for formats missing in Libav or older FFmpeg versions, like AV_PIX_FMT_RGB0 and others.
* video: handle endian detection in a more generic waywm42014-11-051-7/+21
| | | | | | | | | | | | | FFmpeg has only a AV_PIX_FMT_FLAG_BE flag, not a LE one, which causes problems for us: we want to have the LE flag too, so code can actually detect whether a format is non-native endian. Basically, we want to reconstruct the LE/BE suffix all AV_PIX_FMT_*s have. Doing this is hard due to the (messed up) way AVPixFmtDescriptor works. The worst is AV_PIX_FMT_RGB444: this group of formats describe an endian-independent access (since no component actually spans 2 bytes, you only need byte accesses with a fixed offset), so we have to go through some pain.
* video: refuse to allocate image data for hwaccel formatswm42014-11-051-1/+1
| | | | Makes no sense.
* video: get hwaccel flag from pixdescwm42014-11-052-5/+8
|
* player: fix --secondary-sidwm42014-11-041-1/+1
| | | | | | | Use the "default" selection for the ff-index, not the "no" selection. Broken by commit f0f83ff. Fixes #1243.
* vo_opengl: minimal EGL on X11 supportwm42014-11-047-1/+188
| | | | | | Pretty useless and only good for testing. Does not include any form of GLES support.
* x11: rely on the Atom cachewm42014-11-032-15/+9
| | | | | XInternAtom() has a 64 entry hash table to avoid network accesses. Rely on this cache, instead of caching these manually.
* demux: unbreak build with Libavwm42014-11-031-0/+4
| | | | ....
* demux: don't account known range for streams that are EOFwm42014-11-031-2/+4
| | | | | | | | | This influences the demuxer readahead display. If a stream has reached EOF, we want to ignore it for the purpose of this calculation. Note that if a stream contains no packets, it still should cause the value 0s to be displayed (unless it's EOF), because that's just the actual situation.
* demux: fix PTS comparisonwm42014-11-031-2/+4
| | | | | | | | This was relying on the fact that timestamps will always be numerically larger than MP_NOPTS_VALUE, but the trick didn't actually work for MP_PTS_MIN. Be a bit more sincere, and don't rely on this anymore. This fixes the comparison, and avoids the readahead amount displaying as "???" in some situations (since one of the values was NOPTS).
* demux: don't consider stream EOF an underrunwm42014-11-031-1/+1
| | | | | | | | | | | | In this case, we didn't find any new packets for this stream, even though we've read ahead as much as possible. (If reading ahead in this case, the "Too many packets in the demuxer packet queues" error is normally printed.) If we do consider this an underrun, handle_pause_on_low_cache() will pause and show the "buffering" state, which is not useful. Could also happen on very bad interleaving.
* demux_mkv: remove minor code duplicationwm42014-11-031-12/+6
|
* demux_mkv: implement audio skipping/trimmingwm42014-11-034-2/+44
| | | | | | | | | | | | | This mechanism was introduced for Opus, and allows correct skipping of "preroll" data, as well as discarding trailing audio if the file's length isn't a multiple of the audio frame size. Not sure how to handle seeking. I don't understand the purpose of the SeekPreRoll element. This was tested with correctness_trimming_nobeeps.opus, remuxed to mka with mkvmerge v7.2.0. It seems to be correct, although the reported file duration is incorrect (maybe a mkvmerge issue).
* ad_lavc: allow skip samples amount to be larger than 1 packetwm42014-11-031-2/+6
| | | | | Apparently we actually need this. At least the following commit would break without this.
* command: add window-minimized property (X11 only)wm42014-11-027-1/+52
| | | | | | More or less requested by #1237. Should be simple to extend this to other backends.
* command: make window-scale property observablewm42014-11-0215-4/+64
| | | | | | | | | | | | Add a generic mechanism to the VO to relay "extra" events from VO to player. Use it to notify the core of window resizes, which in turn will be used to mark all affected properties ("window-scale" in this case) as changed. (I refrained from hacking this as internal command into input_ctx, or to poll the state change, etc. - but in the end, maybe it would be best to actually pass the client API context directly to the places where events can happen.)
* client API: nothing uses the result parameter of mpv_command_node()wm42014-11-021-0/+2
| | | | | | Add a comment about this to avoid confusing users of this function. The parameter is essentially unused, but exists so that we don't need to add extra APIs if the need for it arises.
* command: expose mpv version as propertywm42014-11-022-0/+12
| | | | A client API user has no other way to know the version.
* common: fix version variable declarationswm42014-11-022-2/+3
| | | | This was stupid.
* player: print anamorphic size only if video is anamorphicwm42014-11-021-2/+5
| | | | Has been annoying me since forever.
* player: always use demux_chapterwm42014-11-0212-51/+47
| | | | | | | | | Instead of defining a separate data structure in the core. For some odd reason, demux_chapter exported the chapter time in nano-seconds. Change that to the usual timestamps (rename the field to make any code relying on this to fail compilation), and also remove the unused chapter end time.
* player: add --chapters-file optionwm42014-11-024-5/+32
| | | | | | | | Note that you can't pass .cue or .edl files to it, at least not yet. Requested in context of allowing to specify custom chapters. For that to work well, we probably need to add some sort of chapter metadata pseudo-demuxer.
* manpage: update --playlist commentswm42014-11-022-9/+10
| | | | | | | | | | | | | | Using the --playlist option is no longer recommended. A while ago, mpv rewrote all playlist parsers and added some minimal security mechanisms (like not allowing local file access or unsafe protocols in remote playlists). Further, mpv can load playlists by passing them as normal file arguments, without the option. Now, --playlist is needed only in these situations: 1) loading plaintext files 2) disabling additional security mechanisms (e.g. using a remote playlist to play local files)
* osd: properly wakeup when the OSD function disappearswm42014-11-011-3/+10
| | | | Fixes #1236.
* cocoa: fix fullscreen delay when pausedStefano Pigozzi2014-11-011-2/+2
| | | | | | NSDisableScreenUpdates came to hunt me in the end and when mpv was paused, it did wait for a frame that never came (because of interaction with the live resizing code)!
* build: remove bundle support from wafStefano Pigozzi2014-11-011-0/+1
| | | | Use TOOLS/osxbundle.py instead. It's just better and less hacky.
* ipc: make it possible to receive log messageswm42014-11-012-0/+23
| | | | | The receiving part was implemented, but since no messages are enabled by default, it couldn't be used.
* ipc: add a command to retrieve API versionwm42014-11-012-0/+8
|
* ipc: verify resume/suspend commandswm42014-11-011-4/+16
| | | | | Calling mpv_resume() too often is considered an API usage violation, and will trigger an internal assertion somewhere.
* manpage: ipc: fix command name for observe_propertywm42014-11-011-1/+1
|
* build: remove bundle support from wafStefano Pigozzi2014-11-012-30/+1
| | | | Use TOOLS/osxbundle.py instead. It's just better and less hacky.
* player: update meaning of drop_frame_cntwm42014-11-015-12/+12
| | | | | Rename the variable, update comments, and update the documentation of the property which returns its value.
* player: show AV-desync message in all framedrop modeswm42014-11-011-2/+1
| | | | | | | | | | | | This was shown only if decoder-framedropping was enabled, and only if at least 50 frames were dropped by it. Since drop_frame_cnt used to mean "number of late frames", this code made sense, but this is not the case anymore: drop_frame_cnt can be even 0, all while video gets hopelessly behind audio. One problem with this is that short desync spikes (which usually can probably dealt with) will also cause this message to be shown. If it gets triggered too often, the code will need to be adjusted.
* build: fix 'ar' invocation when cross-compilingwm42014-11-011-1/+3
| | | | | | | | This shouldn't use the host's 'ar' when building static libs. It only worked until now because Linux 'ar' is usually built with PE support. Couldn't confirm whether it works, because this dumb crap is just broken when cross-compiling to mingw.
* cache: don't relay STREAM_CTRL_AVSEEK if it's unsupportedwm42014-11-011-0/+4
| | | | | | | | Thanks to STREAM_CTRL_HAS_AVSEEK, we actually know whether CTRL_AVSEEK is implemented at all, and we can avoid a blocking wait on the cache if demux_lavf sends CTRL_AVSEEK even if it won't wait. I'm hoping this can't currently happen, but why hope if we can explicitly prevent it. It'll make us more robust against future changes in libavformat.
* sub: remove osd_get_sub()wm42014-11-015-13/+7
| | | | | Trades one strange thing against another, but seems slightly less strange.
* command: don't require whitespace before ';' or '#'wm42014-10-311-4/+1
| | | | | | | This change is probably too simplistic, but most things appear to work, so I don't care about that now. Fixes #1232.
* sub: be more flexible about changes to how subtitles are renderedwm42014-10-311-20/+32
| | | | | | | | | For example, if --force-window is used, and video is switched off during playback, then you need to redecide the rendering method to get subs displayed correctly. Do this by moving the state setup code into a function, and call it on every frame.
* osdep: potentially fix compilation on OpenBSDwm42014-10-311-0/+1
| | | | | The <pthread_np.h> header expects that <pthread.h> was already included. We were including <pthread.h> only later via our threads.h.
* ao_alsa: don't make snd_pcm_hw_params_set_buffer_time_near() error fatalwm42014-10-311-1/+7
| | | | | | | | | | | | | Apparently this can "sometimes" return an error. In my opinion, this should never return an error: neither the semantics of the function, nor the ALSA documentation or ALSA sample code seem to indicate that a failure is to be expected. I'm not perfectly sure about this though (I blame ALSA being a weird, big, underdocumented API). Since it causes problems for some users, and since there is really no reason why we should abort on such an error, turn it into a warning. Fixes #1231.
* player: change framedrop display in the status linewm42014-10-312-12/+14
| | | | | Hopefully less confusing, and hopefully doesn't exceed the terminal width in any situation.
* player: improve exit message in some scenarioswm42014-10-313-63/+58
| | | | | | | | | | | | | | If you played e.g. an audio-only file and something bad happened that interrupted playback, the exit message could say "No files played". This was awkward, so show a different message in this case. Also overhaul how the exit status is reported in order to make this easier. This includes things such as not reporting a playback error when loading playlists (playlists contain no video or audio, which was considered an error). Not sure if I'm happy with this, but for now it seems like a slight improvement.
* options: accept --audio-channels=autowm42014-10-302-2/+4
| | | | This sounds much more intuitive, while "empty" was a bit of a WTF.
* demux_lavf, stream_lavf: drop local buffers on time-seekswm42014-10-302-3/+8
| | | | | There was chance that some data was left in various local buffers after time-seeks. Probably doesn't actually matter.
* demux_lavf: mark as seekable if protocol supports seeking by timewm42014-10-304-0/+11
| | | | | | | | | | | | Basically, this will mark the demuxer as seekable with rtmp* and mmsh protocols. These protocols have network-level time seeking, and whether you can seek on the byte level does not matter. Until now, seeking was typically only enabled because of the cache, and a (nonsensical) warning was shown accordingly. It still could happen that the server doesn't actually support thse requests (or simply rejects them), so this is somewhat imperfect.
* demux_playlist: redirect ASF streaming to mmsh://wm42014-10-301-14/+30
| | | | | | | | | | | | I'm not sure if this could be done in libavformat instead. Probably not, because libavformat doesn't seem to have any mechanism for trying one protocol and reverting (or redirecting) to another one if needed. This commit is sort of a hack too, because it redirects the URL by pretending the http:// link is a playlist containing the mmsh:// link. The list of mime types is borrowed from MPlayer (which has completely different code to handle this).
* client API: qthelper: add set_option_variant()wm42014-10-302-0/+11
|
* vo_opengl: draw OSD twice in 3D mode casewm42014-10-293-7/+57