summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* vf: add function to remove a filter from the chainwm42014-04-212-0/+14
|
* vo_opengl: support rotationwm42014-04-212-15/+48
| | | | | | | | | | | This turned out much more complicated than I thought. It's not just a matter of adjusting the texture coordinates, but you also have to consider separated scaling and panscan clipping, which make everything complicated. This actually still doesn't clip 100% correctly, but the bug is only visible when rotating (or flipping with --vf=flip), and using something like --video-pan-x/y at the same time.
* vo: add some general support code for VOs that allow rotationwm42014-04-214-12/+30
| | | | | | For rotation, we assume that the source image will be rotated within the VO, so the aspect/panscan code needs to calculate its param using rotated coordinates. VOs which support rotation natively can use this.
* vo_opengl: clean up rendering pathwm42014-04-211-76/+94
| | | | | Shuffle the special cases around so that it looks cleaner. The result should be equivalent to the code before.
* demux: export video rotation parameterwm42014-04-213-0/+10
| | | | | Now the rotation hint is propagated everywhere. It just isn't used anywhere yet.
* mp_image: add rotation parameterwm42014-04-212-1/+4
|
* video: make mp_image use mp_image_params directlywm42014-04-216-79/+47
| | | | | Minor cleanup, so that we can stuff more information into mp_image_params later.
* vf_rotate: support all multiples of 90 degreeswm42014-04-213-101/+25
| | | | | | | | | | | | | This couldn't rotate by 180°. Add this, and also make the parameter in degrees, instead of magic numbers. For now, drop the flipping stuff. You can still flip with --vf=flip or --vf=mirror. Drop the landscape/portrait stuff - I think this is something almost nobody will use. If it turns out that we need some of these things, they can be readded later. Make it use libavfilter. Its vf_transpose implementation looks pretty simple, except that it uses slice threading and should be much faster.
* 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-198-20/+36
| | | | | | | | | | | | 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.
* Fix some libav* include statementswm42014-04-198-15/+14
| | | | | | | | | | | | | Fix all include statements of the form: #include "libav.../..." These come from MPlayer times, when FFmpeg was somehow part of the MPlayer build tree, and this form was needed to prefer the local files over system FFmpeg. In some cases, the include statement wasn't needed or could be replaced with mpv defined symbols.
* Remove CPU detection and inline asm handlingwm42014-04-1912-508/+9
| | | | | | | | | | | | | | 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.
* vf_pp: fix include statementwm42014-04-191-1/+1
|
* vf_pp: use native libpostproc CPU detectionwm42014-04-191-5/+1
|
* vf_divtc: remove inline asmwm42014-04-191-50/+0
| | | | | | Becomes a bit slower (tested with progressive solid color video only), but this filter is pretty obscure and I'm not even sure what it's useful for.
* vf_pullup: remove inline asmwm42014-04-193-218/+0
| | | | | | No change in speed (or even slightly faster, though I tested with progressive solid color video only), and normally we use libavformat's vf_pullup anyway.
* vf_noise: remove line asmwm42014-04-191-130/+4
| | | | | | | | I didn't test the speed, but by default, this filter diverts to libavfilter already. So this would help only if libavfilter is disabled, or libavfilter doesn't have vf_noise (like on Libav). For these cases, we still provide the (possibly but not necessarily) slower C implementation of vf_noise.
* vf_ilpack: remove inline asmwm42014-04-191-277/+4
| | | | | | | | This makes it multiple times slower. However, the output format (packed YUV) isn't handled efficiently by anything to begin with, and I have no clue we even have this filter. I guess it's one of these filters which find some use sometimes, but are not of higher importance, which justifies removing the faster inline asm.
* vf_eq: remove slow inline asmwm42014-04-191-75/+0
| | | | | Compiled with -O2, the C code runs just as far (or even slightly faster) then the MMX inline asm.
* manpage: add notes when to use/not use certain AO and VO driverswm42014-04-192-1/+50
|
* encode: disable keep-open when encodingJames Ross-Gowan2014-04-191-0/+1
|
* lua: add example to rebuild the status lineDavid Weber2014-04-191-0/+69
| | | | | | | This can be used to easily extent the status line for one's own needs. I'm not experienced with lua so a few things could probably be done a better way.
* input: make key binds order-independent againwm42014-04-191-2/+7
| | | | | | | | | | | | | | | This is for the sake of multi-key commands again. This could break: SPACE ignore SPACE-SPACE command while this worked: SPACE-SPACE command SPACE ignore The reason being that if the shorter command was first in the list, it would obviously match, and searching was stopped.
* input: discard key history when a key is mappedwm42014-04-192-7/+11
| | | | | | This is for the sake of multi-key combinations (see github issue #718). Now a multi-key sequence isn't matched if any of the previous keys were actually mapped.
* input: remove minor code duplicationwm42014-04-191-15/+16
|
* input: ignore modifiers on MOUSE_LEAVEwm42014-04-191-2/+2
| | | | Just in case something adds shift/alt/ctrl state to it.
* manpage: clarify one aspect of multi-keybindingswm42014-04-181-1/+2
| | | | | The explanation is kind of obvious, but on the other it'd probably be confusing not to clarify this.
* input: don't wakeup core if key repeat is requested but not possiblewm42014-04-181-7/+5
| | | | There's no need to wakeup the core in this situation.
* input: remove minor redundancywm42014-04-181-10/+2
|
* input: keycodes: reorder flagswm42014-04-181-16/+16
| | | | | | | MP_KEY_EMIT_ON_UP and MP_NO_REPEAT_KEY are not modifiers, just static flags that some keycodes set. This is just a cosmetic change.
* input: simplify by not tracking key up/down stateswm42014-04-181-53/+30
| | | | | | | | | We only need to track key up/down for a single key. There may be some minor loss of robustness, but this can (probably) happen only if a VO or user sends strange or complicated sequences of events. In the normal case, what we do is more than enough. Most simplification comes from the fact that mpv is not a game console, and users normally execute only one action at once.
* input: rename a variablewm42014-04-181-5/+5
| | | | Squashing this with the following commit would be confusing.
* input: slightly simplify mouse dispatchingwm42014-04-181-13/+1
| | | | | I admit I don't really understand anymore why this was needed. Delete it anyway. It was added with commit 42fa7cbbf.
* input: move a functionwm42014-04-181-11/+11
|
* input: close window when window close button is pressed with --input-testwm42014-04-183-5/+14
| | | | | | | | | | | The window close button is usually mapped to the CLOSE_WIN pseudo-key. Until now, --input-test treated this pseudo-key like any other key (like the rest of the input handling code), so you couldn't close the window in this mode. The manpage had silly instructions and warnings how to deal with this. Just always quit when CLOSE_WIN is received, and improve the instructions.
* input: handle multi-combinations as key sequenceswm42014-04-182-64/+60
| | | | | | | | | | | | | | | | | The input code always supported combinations of multiple keys (even in MPlayer, although there the code was active really only for mouse buttons). This was arcance and also made the code more complicated. I only know of a single person who ever made use of this feature. Remove this feature, and repurpose some of the support code (e.g. parsing, display of key combinations, etc.) to handle such multi- combinations as sequences, instead of keys to be pressed at the same time. This is much simpler and implements the feature requested in github issue #718. This commit will probably cause a bunch of regressions, since the input handling code has some weird corner cases. I couldn't find any problems when testing, though.
* audio: preallocate audio buffers on resizewm42014-04-181-2/+7
| | | | | | This avoids too many realloc() calls if the caller is appending to an audo buffer. This case is actually quite noticeable when using something that buffers a large amount of audio.
* manpage: document loop-file propertywm42014-04-181-0/+3
| | | | Was forgotten in commit 1b398e99.
* 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-175-0/+20
| | | | Unlike --loop, loops a file instead of the playlist.
* player: unrangle one aspect of audio EOF handlingwm42014-04-174-14/+15
| | | | | | | | | | | | | | | | | | 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.)
* w32_common: use ToUnicode to translate key inputJames Ross-Gowan2014-04-172-50/+184
| | | | | | | | | | | | | | | | This replaces translate_key_input with a solution that gives mpv more control over how keyboard input is converted to unicode. As a result: - Key up/down events are generated the same way for all keys. - Dead keys generate their base character instead of being combined with the following character. - Many Ctrl and Ctrl+Alt key combinations that were previously broken are fixed, since it's possible to discover the base keys. - AltGr doesn't produce special characters when mp_input_use_alt_gr is false. This also fixes some logic to do with detecting AltGr and adds proper UTF-16 decoding.
* audio: add hack against broken pulseaudio EOF conditionwm42014-04-171-1/+16
| | | | | | | | | | | | This was reported with PulseAudio 2.1. Apparently it still has problems with reporting the correct delay. Since ao_pulse.c still has our custom get_delay implementation, there's a possibility that this is our fault, but this seems unlikely, because it's full of workarounds for issues like this. It's also possible that this problem doesn't exist on PulseAudio 5.0 anymore (I didn't explicitly retest it). The check is general and works for all push based AOs. For pull based AOs, this can't happen as pull.c implements all the logic correctly.
* audio: explicitly document audio EOF conditionwm42014-04-172-1/+6
| | | | | | This should probably be an AO function, but since the playloop still has some strange stuff (using the buffered_audio variable instead of calling ao_get_delay() directly), just leave it and make it more explicit.
* ao_null: add simulated device latency, simulate EOF problemswm42014-04-172-3/+26
| | | | | This EOF problems happen at least with PulseAudio, but since it's hard to reproduce, let ao_null optionally simulate it.
* vo_opengl: make spline36 default with --vo=opengl-hqwm42014-04-172-3/+5
|
* player: add a --dump-stats optionwm42014-04-1711-9/+181
| | | | | | | | | | | | | | | | | | | | | | | This collects statistics and other things. The option dumps raw data into a file. A script to visualize this data is included too. Litter some of the player code with calls that generate these statistics. In general, this will be helpful to debug timing dependent issues, such as A/V sync problems. Normally, one could argue that this is the task of a real profiler, but then we'd have a hard time to include extra information like audio/video PTS differences. We could also just hardcode all statistics collection and processing in the player code, but then we'd end up with something like mplayer's status line, which was cluttered and required a centralized approach (i.e. getting the data to the status line; so it was all in mplayer.c). Some players can visualize such statistics on OSD, but that sounds even more complicated. So the approach added with this commit sounds sensible. The stats-conv.py script is rather primitive at the moment and its output is semi-ugly. It uses matplotlib, so it could probably be extended to do a lot, so it's not a dead-end.
* msg: correct ringbuffer log level comparisonFRAU KOUJIRO2014-04-171-1/+1
|
* stream_dvdnav: print more debugging infowm42014-04-171-1/+6
|
* stream_dvd: fix seeking regressionwm42014-04-171-8/+48
| | | | | | | | | | | | This was accidentally completely destroyed with commit 24f1878e. I didn't notice it when testing, because forward seeking still worked mostly. The issue was that dvd_seek_to_time() actually called stream_seek(), which was supposed to call the byte-level seek function dvd_seek(). So we have to restore this function, and replace all generic stream calls with stream_dvd.c internal ones. This also affects stream->pos (now a random number as far as stream_dvd.c is concerned) and stream_skip().
* ao: remove redundant get_delay checkwm42014-04-171-4/+0
| | | | It did nothing; the real check is in push.c.
* wayland: unset input regions for osdAlexander Preisinger2014-04-161-0/+4
| | | | | Set a zero sized input region for the osd surfaces in order to avoid getting input for the subsurfaces which might dissapear any time.
* wayland/shm: Use subsurfaces for OSDAlexander Preisinger2014-04-164-29/+133
|
* af_lavcac3enc: detach on any passthrough format, not just ac3wm42014-04-161-1/+1
|
* input: deal with playback thread wakeup on windowswm42014-04-151-3/+14
| | | | | | | | | | | | | The recent change of waking up the playback thread using a wakeup pipe doesn't work on windows, because windows is horrible. So use a condition variable instead to wake up the thread. To make things worse, jackaudio is also horrible and "disallows" the use of mutexes, so all we can do is implementing a half-solution that is not race condition free. It would probably better to give up on this lock-free crap in the pull- API audio path. Mostly untested.
* player: remove audio waitingwm42014-04-151-16/+0
| | | | | | | | The audio subsystem now wakes up the playback thread explicitly, and we don't need this anymore. It still could cause dropouts and such if there are bugs in the recently introduced audio changes, so this is a thing to watch out for.
* audio: wake up the core when audio buffer is running low (2)wm42014-04-153-2/+17
| | | | | | | | | | | | | | Same change as in e2184fcb, but this time for pull based AOs. This is slightly controversial, because it will make a fast syscall from e.g. ao_jack. And according to JackAudio developers, syscalls are evil and will destroy realtime operation. But I don't think this is an issue at all. Still avoid locking a mutex. I'm not sure what jackaudio does in the worst case - but if they set the jackaudio thread (and only this thread) to realtime, we might run into deadlock situations due to priority inversion and such. I'm not quite sure whether this can happen, but I'll readily follow the cargo cult if it makes hack happy.
* ao_pulse: use ao_need_data()wm42014-04-151-2/+2
| | | | | | | | | I'm not quite sure why ao_pulse needs this. It was broken when a thread to fill audio buffers was added to AO - the pulseaudio callback was waking up the playback thread, not the audio thread. But nobody noticed, so it can't be very important. In any case, this change makes it wake up the audio thread instead (which in turn wakes up the playback thread if needed).
* audio: wake up the core when audio buffer is running lowwm42014-04-152-15/+61
| | | | | | | | | | | | | | | | | And also add a function ao_need_data(), which AO drivers can call if their audio buffer runs low. This change intends to make it easier for the playback thread: instead of making the playback thread calculate a timeout at which the audio buffer should be refilled, make the push.c audio thread wakeup the core instead. ao_need_data() is going to be used by ao_pulse, and we need to workaround a stupid situation with pulseaudio causing a deadlock because its callback still holds the internal pulseaudio lock. For AOs that don't call ao_need_data(), the deadline is calculated by the buffer fill status and latency, as before.
* video: remove use of deprecated AVFrame fields on Libavwm42014-04-151-4/+0
| | | | | | qscale export has been completely removed from Libav 10, and FFmpeg has an alternative API, so this code does nothing and only causes deprecation warnings on Libav.
* README: mention minimum FFmpeg/Libav versionswm42014-04-151-0/+1
|
* client API: remove mpv_event_pause_reasonwm42014-04-148-98/+28
| | | | | | | | | And slightly adjust the semantics of MPV_EVENT_PAUSE/MPV_EVENT_UNPAUSE. The real pause state can now be queried with the "core-idle" property, the user pause state with the "pause" property, whether the player is paused due to cache with "paused-for-cache", and the keep open event can be guessed with the "eof-reached" property.
* command: add property to indicate when pausing due to --keep-openwm42014-04-145-2/+23
| | | | | | | This property is set to "yes" if playback was paused due to --keep-open. The change notification might not always be perfect; maybe that should be improved.
* command: add a property to indicate core pause statewm42014-04-142-2/+16
| | | | | | | | | Currently this is (probably) equivalent to "paused-for-cache", but the latter is a bit special, while this new property is a bit more general. One case where they might actually be different is dvdnav menus, but I haven't checked. Also add property change notifications for these two properties.
* vf_vapoursynth: handle destruction more gracefullywm42014-04-141-7/+8
| | | | | | | | | | | | | | We were relying on vsscript_freeScript() to take care of proper termination. But it doesn't do that: it doesn't wait for the filters to finish and exit at all. Instead, it just destroys all objects, which causes the worker threads to crash sometimes. Also, we're supposed to wait for the frame callback to finish before freeing the associated node. Handle this by explicitly waiting as far as we can. Probably fixes crashes on seeking, although VapourSynth itself might also need some work to make this case completely stable.
* options: don't allow --no-foo=yeswm42014-04-141-2/+2
| | | | | | | | | It's a bit strange to allow this, so get rid of it. This probably breaks a bunch of user config files. The client API still allows setting them with MPV_FORMAT_FLAG w