summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
* cocoa: only call resize for view changing frameStefano Pigozzi2014-10-042-5/+2
|
* cocoa: remove pointless drawRectStefano Pigozzi2014-10-041-7/+0
| | | | | | Apparently it causes deadlocks, and at the moment it does nothing. Fixes #778
* cocoa: make fullscreening look like an atomic operationStefano Pigozzi2014-10-041-0/+16
| | | | | | | | | | | At the moment when you fullscreen mpv there is a very small time interval where the fullscreen windows is semi-transparent. Apparently whem moving the view to another parent it's better to make Cocoa not draw anything globally. An Apple engineer said it, so it must be correct: http://www.cocoabuilder.com/archive/cocoa/142020-preventing-flicker-on-moving-nsview-to-different-superview.html I know I will regret this in the future.
* cocoa: make resizing wake the vo threadStefano Pigozzi2014-10-041-0/+1
|
* cocoa: remove dead codeStefano Pigozzi2014-10-042-19/+0
|
* vf_stereo3d: fix "auto" input format with libavAlessandro Ghedini2014-10-041-1/+1
|
* manpage: refactor MPlayer -> mpv changes sectionAlessandro Ghedini2014-10-041-90/+137
| | | | Merge duplicate entries, organize entries in subsections, reword some entries.
* x11: stupid workaround for XMonadwm42014-10-043-7/+21
| | | | | | | | --x11-netwm=yes now forces NetWM fullscreen, while --x11-netwm=auto (detect whether NetWM fullsctreen support is available) is the old behavior and still the default. See #888.
* ad_lavc: avoid warning messages on older FFmpeg or Libavwm42014-10-041-0/+2
| | | | | If the flag doesn't exist, the av_opt_set() API will print warning messages.
* cocoa: move to a simpler threading modelStefano Pigozzi2014-10-047-114/+37
| | | | | | | | | | | | | | Unfortunately using dispatch_sync for synchronization turned out to be really bad for us. It caused a wide array of race conditions, deadlocks, etc. Moving to a very simple mutex. It's not clear to me how to do liveresizing with this, for now it just flickers with is unacceptable (maybe I'll draw black instead). This should fix all the threading cocoa bugs. Reopen if it's not the case! Fixes #751 Fixes #1129
* build: fix examples target pathsStefano Pigozzi2014-10-041-3/+3
| | | I 'broke' it in 78c362b. Sorry!
* build: allow to compile the cocoabasic.m exampleStefano Pigozzi2014-10-041-3/+9
|
* manpage: improve consistency with new ~/.config/mpv defaultKevin Mitchell2014-10-044-27/+32
| | | | Signed-off-by: wm4 <wm4@nowhere>
* player: move some libass setup code to sub.cwm42014-10-034-96/+100
| | | | | | | | | | | | | | | Also recreate ASS_Library on every file played. This means we can move the code out of main.c as well. Recreating the ASS_Library object has no disadvantages, because it literally stores only the message callback, the (per-file) font attachment as byte arrays, and the set of style overrides. Hopefully this thing can be removed from the libass API entirely at some point. The only reason why the player core creates the ASS_Renderer, instead of the subtitle renderer, is because we want to cache the loaded fonts across ordered chapter transitions, so this probably still has to stay around for now.
* player: properly wakeup when delaying OSDwm42014-10-031-1/+3
| | | | | | | Not sure in which situations this could make a difference; probably none in practice, but it's more correct. CC: @mpv-player/stable
* video: return responsibility of video redraw back to playloopwm42014-10-033-4/+22
| | | | | | | | | | | | | | | | | | | | | | | | When the VO was moved it its own thread, responsibility for redrawing was given to the VO thread itself. So if there was a condition that indicated that redrawing was required, like expose events or certain VOCTRLs, the VO thread was redrawing itself. This worked fine, but there are some corner cases where this works rather badly. E.g. if I fullscreen the player and hit panscan controls with mpv's default autorepeat rate, playback stops. This happens because the VO redraws itself after every panscan change command. Running each (repeated) command takes so long due to redrawing and (involuntary) waiting on vsync, that it never leaves the input processing loop while the key is held down. I suspect that in my case, redrawing in fullscreen mode just gets slow enough that it takes 2 vsyncs instead of 1 on average, and the processing time gets larger than the autorepeat delay. Fix this by taking redraw control from the VO, and instead let the playloop issue a "real" redraw command to the VO if needed. This basically reverts redraw handling to what it was before moving the VO to a thread. CC: @mpv-player/stable
* player: remove central uninit_player() function and flags messwm42014-10-039-227/+184
| | | | | | | | | | | | | | Each subsystem (or similar thing) had an INITIALIZED_ flag assigned. The main use of this was that you could pass a bitmask of these flags to uninit_player(). Except in some situations where you wanted to uninitialize nearly everything, this wasn't really useful. Moreover, it was quite annoying that subsystems had most of the code in a specific file, but the uninit code in loadfile.c (because that's where uninit_player() was implemented). Simplify all this. Remove the flags; e.g. instead of testing for the INITIALIZED_AO flag, test whether mpctx->ao is set. Move uninit code to separate functions, e.g. uninit_audio_out().
* ao_pulse: refuse to start suspendedwm42014-10-031-1/+1
| | | | | | | | | | | | Sometimes, ao_pulse starts in suspended mode, which means playback is essentially paused in pulseaudio. This gives the impression that mpv is hanging, since it times video against the audio playback progress, and audio never makes progress in this state. I'm not sure if this will help - possibly it does with mixed pulseaudio/alsa setups. However, if the alsa setup has the pulseaudio plugin, alsa will hang too. But there's still a chance we get less blame for pulseaudio messes.
* audio: skip samples and adjust timestamps ourselveswm42014-10-033-2/+34
| | | | | | | | | | This gets rid of this warning: Could not update timestamps for skipped samples. This required an API addition to FFmpeg (otherwise it would instead doing arithmetic on the timestamps itself), so whether it works depends on the FFmpeg version.
* man: replaced : with , in broken --lua-opts osc exampleStephen Caraher2014-10-031-1/+1
| | | | | | | --lua-opts is a key-value list, so the option parser accepts only commas. Signed-off-by: wm4 <wm4@nowhere> CC: @mpv-player/stable
* command: don't show message on "osd" command by defaultwm42014-10-031-3/+2
| | | | | | Apparently this was not very popular. CC: @mpv-player/stable
* command: allow passing memory addresses to overlay_addwm42014-10-032-0/+16
| | | | | | | | | For the sake of libmpv. Might make things much easier for the user, especially on Windows. On the other hand, it's a bit sketchy that a command exists that makes the player access arbitrary memory regions. (But do note that input commands are not meant to be "secure" and never were - for example, there's the "run" command, which obviously allows running random shell commands.)
* command: restructure overlay_add codewm42014-10-031-46/+63
| | | | | | | | | Somewhat more flexible: now there's a separate overlay struct, and you don't need to coerce all state into struct sub_bitmap. Also, removing the previous mapping (munmap call) is now all in one place, the replace_overlay function. Makes the next commit easier to implement.
* manpage: remove non-existing ratio-pos propertywm42014-10-021-3/+0
| | | | | | | | | | Use percent-pos instead, which is exactly the same, except with the range 0.0-100.0. I'm not sure how this got there; it was probably introduced and then removed again as percent-pos got more precise. CC: @mpv-player/stable
* x11: fix --wid=0wm42014-10-021-0/+1
| | | | | | | | | | Another fallout resulting from the changes whether or not to wait for mapping the window. In this case, it obviously makes no sense to wait for mapping, because the root window is always mapped. Mapping will never happen, and it would wait forever. Fixes #1139. CC: @mpv-player/stable
* manpage: redocument audio delay key bindingswm42014-10-021-0/+3
| | | | | Fixes #1131. CC: @mpv-player/stable
* player: don't print audio/video init failure message twicewm42014-10-022-3/+4
| | | | | | | The messages "Audio: no audio" and "Video: no video" could be printed twice each if initializing them failed. Prevent his silliness. CC: @mpv-player/stable
* audio: enable pitch correction by default when playing fastwm42014-10-024-2/+49
| | | | | | | Apparently this is what users want. When playing with normal speed, nothing is done. When playing slower than normal, resampling is used instead, because scaletempo (which does the pitch correction) adds too many artifacts.
* audio/filter: allow removing filters by labelwm42014-10-022-1/+33
| | | | | | | | Although the "af" command already could do this, it seems it's better to introduce a lower level mechanism for now. This avoids some messy issues, since that code would recursive call reinit_audio_chain(). To be used by the next commit.
* command: move setting playback speed to a separate functionwm42014-10-023-10/+19
|
* audio: refactor some aspects of filter chain setupwm42014-10-025-104/+56
| | | | | | | | | | | There's no real reason why audio_init_filter() should exist. Just use af_init or af_reinit directly. (We lose a useless message; the same information is printed in a quite close place with more details.) Requires less code, and the way the filter chain is marked as having failed to initialize allows just switching off audio instead of crashing if trying to insert a volume filter in mixer.c fails, and recreating the old filter chain fails too.
* audio/filter: don't wipe full filter chain if adding a filter failswm42014-10-021-2/+5
| | | | | There's no need for that, and in fact makes it more likely that it recovers normally.
* sub: round scaled subtitleswm42014-10-021-4/+4
| | | | | | | | | Simple fix for issue #1137. Since all sub-bitmaps are packed on a larger texture, there's still a "fall off" on the border due to the linear scaling. This could be fixed by constraining each sub-bitmap to its own texture, or by clamping on the shader level, but I don't care for now.
* vo_vdpau: don't try to create surfaces of size 0wm42014-10-012-11/+11
| | | | | | | | | | | | | | | | | | | | | | At least on kwin, we decide to proceed without waiting for the window being mapped (due to the frame exts hack, see commit 8c002b79). But that leaves us with a window size of 0x0, which causes VdpOutputSurfaceCreate to fail. This prints some warnings, although vo_vdpau recovers later and this has no other bad consequences. Do the following things to deal with this: - set the "known" window size to the suggested window size before the window is even created - allow calling XGetGeometry on the window even if the window is not mapped yet (this should work just fine) - make the output surface minimum size 1x1 Strictly speaking, only one of these would be required to make the warning disappear, but they're all valid changes and increase robustness and correctness. At no point we use a window size of 0x0 as magic value for "unset" or unknown size, so keeping it unset has no purpose anyway. CC: @mpv-player/stable
* demux_disc: bluray: fix stream language (2)wm42014-09-301-0/+1
| | | | | | | | | Commit 50e131b43ed happened to make it work for DVD (because the higher bits of the ID are masked in the DVD case), but failed for Bluray. This probably fixes it, although I don't have a sample to multiple streams to confirm it really does it right. CC: @mpv-player/stable
* man: fix to->too typoKevin Mitchell2014-09-301-1/+1
|
* audio: remove --audiodropwm42014-09-305-24/+0
| | | | | | | | | | | | | | | This would play some silence in case video was slower than audio. If framedropping is already enabled, there's no other way to keep A/V sync, short of changing audio playback speed (which would give worse results). The --audiodrop option inserted silence if there was more than 500ms desync. This worked somewhat, but I think it was a silly idea after all. Whether the playback experience is really bad or slightly worse doesn't really matter. There also was a subtle bug with PTS handling, that apparently caused A/V desync anyway at ridiculous playback speeds. Just remove this feature; nobody is going to use it anyway.
* w32_common: quit event loop on destroyJames Ross-Gowan2014-09-301-6/+11
| | | | | | | | | | | | When embedding, if the parent window is destroyed, it will cause mpv's window to be destroyed as well. Since WM_USER wakeups are sent to the window, destroying the window will prevent wakeups and cause uninit to hang. Fix this by quitting the event loop on WM_DESTROY. Events should only be processed for the lifetime of the window, from CreateWindowEx to WM_DESTROY. After the event loop is finished, mp_dispatch_queue_process can handle any remaining requests.
* vd_lavc: fix a small memory leak on init errorwm42014-09-292-8/+5
| | | | | The private context wasn't free'd when codec init failed. Restructure the code so that it can't happen.
* x11: always wait for mapped when using --widwm42014-09-291-2/+3
| | | | | | | Might help with embedding with mozplugger. I can't confirm whether it fixes the issue. See #1090.
* demux_disc: export BD/DVD audio languagewm42014-09-291-0/+1
| | | | This was "forgotten".
* stream: don't drop buffers on failed seekswm42014-09-291-6/+2
| | | | | | | | | | | Might matter when libavformat tries to do tiny seekbacks in an unseekable stream, and the seekback buffer isn't large enough. In this case, seeking would fail, and would drop the current buffer. The seekback would end up dropping future data. This change probably doesn't have any observable effects. libavformat normally has its own stream buffer, and demux_mkv.c tries carefully never to seek back.
* cache_file: refuse to cache unseekable streamswm42014-09-291-0/+5
| | | | | | | | | This makes no sense to use with DVD/BD/DVB and some others, and these streams happen to be unseekable. Also, other kinds of unseekable streams (like reading from pipe) should work, but will exhibit sketchy behavior if they need to seek. So just disable it, and leave these problems to the memory cache (cache.c).
* demux_lavf: bluray: don't skip stream data when flushingwm42014-09-291-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This code meant to flush demuxer internal buffers by doing a byte seek to the current position. In theory this shouldn't drop any stream data. However, if the stream positions mismatch, then avio_seek() (called by av_seek_frame()) stops being a no-op, and might for example read some data to skip to the seek target. (This can happen if the distance is less than SHORT_SEEK_THRESHOLD.) The positions get out of sync because we drop data at one point (which is what we _want_ to do). Strictly speaking, the AVIOContext flushing is done incorrectly, becuase pb->pos points to the start of the buffer, not the current position. So we have to increment pb->pos by the buffered amount. Since there are other weird reasons why the positions might go out of sync (such as stream_dvd.c dropping buffers itself), and they don't necessarily need to be in sync in the first place unless AVIOContext has nothing buffered internally, just use the sledgehammer approach and correct the position manually. Also run av_seek_frame() after this. Currently, it shouldn't read anything, but who knows how that might change with future libavformat development. This whole change didn't have any observable effect for me, but I'm hoping it fixes a reported problem.
* demux_disc: bluray: potentially fix some aspects of seekingwm42014-09-292-1/+7
| | | | | | | | | | | | | When flushing the AVIOContext, make sure it can't seek back to discarded data. buf_ptr is just the current read position, while buf_end - buffer is the actual buffer size. Since mpegts.c is littered with seek calls, it might be that the ability to seek could read Mark the stream (which the demuxer uses) as not seekable. The cache can enable seeking again (this behavior is sometimes useful for other things). I think this should have had no bad influence in theory, since seeking BD/DVD first does the "real" seek, then flushes libavformat and reads new packets.
* mpv.desktop: add more ogg-related mime typesAlessandro Ghedini2014-09-291-1/+1
| | | | Also adds audio/ogg and video/ogg.
* lua: add mpv/lua directories to the lua pathOtto Modinos2014-09-282-3/+33
| | | | Signed-off-by: wm4 <wm4@nowhere>
* DOCS/client_api_examples: qtexample: remove broken resizingwm42014-09-281-8/+6
| | | | | | | | | The intention was to adjust the window size to video size. It never worked well; it prevented the user to make the window smaller. For unknown reason it stopped resizing properly as well. This is just a cheap example, and I don't intend to fight with Qt, so replace the "demonstration" behavior by something slightly lamer.
* client API, X11: change default keyboard input handling againwm42014-09-289-13/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | Commit 64b7811c tried to do the "right thing" with respect to whether keyboard input should be enabled or not. It turns out that X11 does something stupid by design. All modern toolkits work around this native X11 behavior, but embedding breaks these workarounds. The only way to handle this correctly is the XEmbed protocol. It needs to be supported by the toolkit, and probably also some mpv support. But Qt has inconsistent support for it. In Qt 4, a X11 specific embedding widget was needed. Qt 5.0 doesn't support it at all. Qt 5.1 apparently supports it via QWindow, but if it really does, I couldn't get it to work. So add a hack instead. The new --input-x11-keyboard option controls whether mpv should enable keyboard input on the X11 window or not. In the command line player, it's enabled by default, but in libmpv it's disabled. This hack has the same problem as all previous embedding had: move the mouse outside of the window, and you don't get keyboard input anymore. Likewise, mpv will steal all keyboard input from the parent application as long as the mouse is inside of the mpv window. Also see issue #1090.
* Fix build with libavfilter disabledwm42014-09-281-1/+1
| | | | Although I'm not sure why we even support this.
* stream_bluray: autodetect AVCHD directorieswm42014-09-271-3/+4
| | | | Fixes #1127.
* video: change automatic rotation and 3D filter insertionwm42014-09-273-17/+114
| | | | | | | | | | | | | | | | | | | | | We inserted these filters with fixed parameters, which was ok. But this also didn't change image parameters for the filters down the filter chain and the VO. For example, if rotation by 90° was requested by the file, we would insert a filter and rotate the video, but the VO would still receive image parameters that direct rotation by 90°. This wasn't a problem, but it could become one. Fix this by letting the filters automatically pick up the image params. The image params are reset on application. (We could probably also always try to apply and reset image params in a filter, instead of having special "auto" parameters. This would probably work, and video.c would insert a "rotate=0" filter. But I'm afraid this would be confusing and the current solution is cosmetically slightly nicer.) Unfortunately, the vf_stereo3d.c change turned out a big mess, but once the "internal" filter is fully replaced with libavfilter, most of this can be radically simplified.
* vf_lavfi: make chaining from other filters more flexiblewm42014-09-273-26/+45
| | | | | | | | | Some filters exists only to create a specific lavfi graph. Allow these filters to reset the graph exactly on reconfig, and allow them to modify some image parameters too. Also make vf_lw_update_graph() behave like vf_lw_set_graph() - they had a subtitle difference with filter==NULL. Useful for the following commit.
* input: copy options automaticallywm42014-09-271-36/+29
| | | | | | Originally, all options were copied to ensure that input_ctx remins thread-safe, even if options are changed asynchronously. But this got a bit inconsistent. Copy them automatically and reduce some weirdness.
* input: separate creation and loading of configwm42014-09-273-15/+25
| | | | | | | | | | | Until now, creating the input_ctx was delayed until the command line and config files were parsed. Separate creation and loading so that input_ctx is available from start. This should make it possible to simplify some things. For example, some complications with Cocoa were apparently only because input_ctx was available only "later". (Although I'm not sure if this is still relevant, or if the Cocoa code should even be organized this way.)
* stream: change malloc+memset to callocBruno George Moraes2014-09-273-8/+2
| | | | | | | Also removed some memset that were left on some calloc that was already in the code. Signed-off-by: wm4 <wm4@nowhere>
* audio/out/push: clean up properly on init errorwm42014-09-271-9/+16
| | | | Close the wakeup pipes, free the mutex and condition var.
* audio/out: check device buffer size for push.c onlywm42014-09-272-7/+5
| | | | Should fix #1125.
* audio/out: disable ao_sndio by defaultwm42014-09-262-4/+5
| | | | | Don't build it, move it down the autoprobe list even if it's enabled. It doesn't work well enough.
* audio/out: fail init on unknown audio bufferwm42014-09-261