summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* x11: replace--[x11-]fstype option with --x11-netwmwm42014-05-167-161/+36
| | | | | Simplifies the code a lot. You can still use --x11-netwm=no to disable NetWM for whatever reasons.
* x11: remove a MWM hackwm42014-05-161-11/+0
| | | | This was for Motif Window Manager. No, I don't care about Motif.
* x11: remove unused stuffwm42014-05-161-18/+0
| | | | | Unfortunately, it looks like some Motif functionality is still needed to allow for --no-border.
* x11: set the fullscreen state before mapping the windowwm42014-05-151-0/+11
| | | | | | | This should get rid of some flickering. Since this actually skips all the wacky fullscreening code on startup, this might lead to certain wacky features to stop working. In this case, you'll have to use the --x11-fstype option, and disable _NETWM_STATE_FULLSCREEN usage.
* x11: clear window on mapwm42014-05-151-1/+1
| | | | | | | | | | | | | | | | vo_x11_map_window() was attempting to clear the window on map. However, it did so immediately after the map request. It probably assumed that the drawing calls for clearing the window would be queued along with the map request, and then executed in the right order. However, this assumption was wrong - the map request first has to go to the window manager (I guess?), so a lot of things happen before the window is even mapped. Fix this by moving the call to the MapNotify message handler, when the window (apparently) becomes really visible. I also tried to set CWBackPixel to black instead, but this seemed to result in flickering on manual resizing.
* x11: wait until the window is mappedwm42014-05-151-0/+11
| | | | | | | | | | | This blocks everything, until the window is actually reported as mapped. This fixes the race condition between VO initialization and mapping the window, which resulted in possibly different window sizes, leading to an immediate redraw, visible as flashing. Note that if the map event never comes for some reason, we're out of luck and will block forever.
* TOOLS/vf_dlopen: use new pixelformats, fix usage for newstyle argsKevin Mitchell2014-05-156-13/+13
|
* vf_dlopen: update usage message to new-style argsKevin Mitchell2014-05-151-1/+1
|
* vf_dlopen: remove buggy private name -> imgfmt conversionKevin Mitchell2014-05-152-34/+18
| | | | | This was presumably for backward compatibility, but it was preventing the use of the new names.
* vf_vapoursynth: fix debug outputwm42014-05-151-1/+4
|
* vf_vapoursynth: add more debug outputwm42014-05-151-18/+21
| | | | | Also, move num_requested() to where it's used. Remove newlines from VS error messages. Remove an assert(0) on an error path.
* manpage: changes.rst: minor fixupswm42014-05-151-5/+5
|
* vf_vapoursynth: avoid unnecessary waitingwm42014-05-141-1/+1
| | | | | | | It could in theory happen that the filter loop will enter a blocking wait, even though it could make progress by emptying the list of already-filtered images. I'm not quite sure if this could actually cause a real issue - probably not.
* TOOLS/mpv_identify.sh: unbreakwm42014-05-141-1/+1
|
* vf_vapoursynth: allow parallel processingwm42014-05-142-45/+101
| | | | | | | | VapourSynth won't just filter multiple frames at once on its own. You have to request multiple frames at once manually. This is what this commit introduces: a sub-option controls how many frames will be requested at once. This also changes the semantics of the maxbuffer sub- option, now renamed to buffered-frames.
* manpage: updates changes.rstwm42014-05-141-46/+59
| | | | | | | | | | | | | The situation has changed a bit since the days of mplayer2, so we can use more/less diplomatic wording. Merge the two sections listing changes from MPlayer and mplayer2. Mention the client API and Lua scripting as alternatives to slave mode. I'm calling MPlayer code "horrible". This is not meant as an offense, but after turning around almost every line of MPlayer code, I believe I have a right to say this. Sorry. I would say that MPlayer has a surprisingly sane and simple architecture (for what it is), but much of it drowned under a load of evil hacks or not-cleaned-up-yet code.
* old-build: accidental rewritewm42014-05-142-2058/+484
| | | | | | | | | | | | | This started as a bunch of smaller changes to make the old configure script maintainable with minimum effort. It ended up as complete rewrite, because at once point I started to like shell programming (I hope this sickness is curable), and I wanted to see how small I can make the configure script. The typical configure test is now 1 or 2 lines big, located in 1 or 2 places, instead of >15 lines and being spread over 5 or 6 places. The main "trick" is factoring the tests into a few generic, commonly needed tests, instead of writing everything manually.
* old-build: drop support for anything but Linux, simplifywm42014-05-142-849/+58
| | | | | | | | | | | | | A lot of effort was spent on making the waf based build-system work properly on all supported platforms, while the old configure script was neglected. It seems that nobody maintains the non-Linux parts of the configure script anymore, and all improvements go into the waf scripts. Thus it makes no sense anymore to maintain the non-Linux parts. They're just dead weight. Remove them completely. Also apply some additional simplifications. For example, listing enabled/disabled VO modules seems like a waste of effort.
* build: add some warning cflagswm42014-05-141-1/+3
| | | | | | | | | These were in the old configure script too. Two flags are explicitly tested, because I have no idea how widespread support for them is, and testing them is just easier than trying to look them up in various gcc/clang manuals. There are people using gcc 4.2 out there, so some caution is warranted.
* wayland: fix typoAlexander Preisinger2014-05-141-14/+14
| | | | So long in the code without me noticing. Embarassing!
* player: reorganize how lua scripts are loadedwm42014-05-1311-130/+209
| | | | | | 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.
* old-build: define a new symbolwm42014-05-131-0/+1
| | | | | | | waf has a proper test, but no test was added to old-configure. This means that on OSX, old-configure is not supposed to work anymore. But still allow it to compile cleanly on OSX.
* stream_smb: increase to 128k read_chuuk from default 8kKevin Mitchell2014-05-121-0/+1
| | | | | | | | | | | | | | | | | Previous to this commit, read_chunk was not set in stream_smb. The cache was therefore filled in small 8K chunks. This resulted in poor performance when compared to, for example, smbnetfs on the same network. The value of 128k is chosen both because it is emperically the "levelling off point" for throughput into mpv's cache, and because it is the value chosen by smbnetfs when serving smb shares to mpv. Note that this change has no effect unless --cache is explicitly specified as smb:// streams do not activate cache by default. This is because the default cache size of 320K is so small it actually makes smb:// perfomance worse. For best results use at least --cache=1024.
* player: disable hr-seek framedropping during backsteppingwm42014-05-121-2/+3
|
* build: fix OpenBSD DVD/CDROM device nameswm42014-05-121-2/+2
| | | | Closes #781.
* vda: Hwaccel 1.2 supportLuca Barbato2014-05-123-34/+81
| | | | Use the new context and the default functions provided.
* vda: Simplify codec selectionLuca Barbato2014-05-121-28/+2
| | | | VDA supports h264 only.
* vd_lavc: Support hwaccel 1.2 and laterLuca Barbato2014-05-121-4/+4
| | | | | Hwaccel 1.2 populates only the third data field and assumes that the AVCodecContext is available to the dealloc function.
* audio/out: fix previous commitwm42014-05-111-9/+11
| | | | | | | | | This didn't quite work. The main issue was that get_space tries to be clever to reduce overall buffering, so it will cause the playloop to decode and queue only as much audio as is needed to refill the AO in reasonable time. Also, even if ignoring the problem, the logic of the previous commit was slightly broken. (This required a few retries, because I couldn't reproduce the issue on my own machine.)
* audio/out: avoid wakeup feedback loopwm42014-05-111-2/+7
| | | | | | | | | | | | | When the audio buffer went low, but could not be refilled yet, it could happen that the AO playback thread and the decode thread could enter a wakeup feedback loop, causing up to 100% CPU usage doing nothing. This happened because the decoder thread would wake up the AO thread when writing 0 bytes of newly decoded data, and the AO thread in reaction wakes up the decoder thread after writing 0 bytes to the AO buffer. Fix this by waking up the decoder thread only if data was actually played or queued. (This will still cause some redundant wakeups, but will eventually settle down, reducing CPU usage close to ideal.)
* TOOLS/stats-conv: don't crash on empty lineswm42014-05-111-0/+3
|
* TOOLS/stats-conv: draw playloop and AO thread events separatelywm42014-05-111-0/+5
| | | | | Use for all AO thread events y=0.5, while playloop events remain at y=1. This makes the graph easier to read.
* manpage: update --playlist entrywm42014-05-111-5/+10
|
* mixer: make code more readablewm42014-05-111-7/+3
| | | | | You wouldn't have guessed that the bottom-most "level[i] = 0.f;" line was actually required. It even confused cppcheck.
* audio/out: more debugging info for --dump-statswm42014-05-111-1/+5
|
* wayland: fix unchecked malloc usagewm42014-05-111-3/+9
| | | | | | | Found by cppcheck. Actually untested. (This is the file drag&drop code, I don't even know which wayland clients support this.)
* 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.
* build: removed undefined behavior from PVR checkwm42014-05-111-1/+1
| | | | | | | | This shouldn't matter, but it's probably better if the code to check is valid - otherwise an extremely clever compiler might fail to compile it, and the feature would be misdetected. (Probably.) Found by cppcheck.
* demux_playlist: fix m3u detection logicwm42014-05-111-1/+1
| | | | | | | | | Caused failure to detect .pls files, because they were misdetected as m3u. The problem is that "forcing playlist files" and "forcing a specific playlist format" are not really treated separate, and in both cases p->force is set to true. This made m3u detect all files as m3u if --playlist was used. So correctly check whether the file format is actually being probed or not.
* manpage: minor correctionswm42014-05-113-8/+10
|
* input: remove pausing command prefixeswm42014-05-114-17/+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.
* old-makefile: add a missing source directorywm42014-05-101-0/+1
| | | | Fixes "make clean".
* ao_coreaudio: skip unknown channel labelsStefano Pigozzi2014-05-101-0/+2
| | | | | | | | | | | | | I don't think this is really a very good idea because it is conceptually incorrect but other prominent multimedia programs use this approach (VLC and xbmc), and it seems to make the conversion more robust in certain cases. For example it has been reported, that configuring a receiver that can output 7.1 to output 5.1, will make CoreAudio report 8 channel descriptions, and the last 2 descriptions will be tagged kAudioChannelLabel_Unknown. Fixes #737
* ao_coreaudio: remove useless codeStefano Pigozzi2014-05-101-15/+0
| | | | | This code doesn't actually makes much of a difference, and the AudioUnit mostly wants layout tags anyway.
* ao_coreaudio: don't fallback to full waveextStefano Pigozzi2014-05-101-4/+5
| | | | | | The code was falling back to the full waveext chmap_sel when less than 2 channels were detected. This new code is slightly more correct since it only fills the chmap_sel with the stereo or mono chmap in the fallback case.
* ao_coreaudio: cosmetic change of loop ending conditionStefano Pigozzi2014-05-101-1/+1
|
* ao_coreaudio: print an error when channel mapping failsStefano Pigozzi2014-05-101-1/+5
|
* ao_coreaudio: use description-based channel layoutsStefano Pigozzi2014-05-103-89/+54
| | | | | | | | | | | | CoreAudio supports 3 kinds of layouts: bitmap based, tag based, and speaker description based (using either channel labels or positional data). Previously we tried to convert everything to bitmap based channel layouts, but it turns out description based ones are the most generic and there are built-in CoreAudio APIs to perform the conversion in this direction. Moreover description based layouts support waveext extensions (like SDL and SDR), and are easier to map to mp_chmaps.
* ao_coreaudio: pass layout by reference to logging functionStefano Pigozzi2014-05-101-7/+7
| | | | | Apparently passing the struct by value somehow messed with the value of some fields.
* chmap_sel: add channel replacement for sl/sr <-> sdl/sdrStefano Pigozzi2014-05-101-16/+21
| | | | | This can be use useful for the 7.1 rear layout. In particular it looks like OS X likes to use sdl/sdr as opposed to sl/sr.
* x11: fix potentially unaligned access in icon loaderwm42014-05-101-3/+3
| | | | | Tried to load a 32 bit value by dereferencing a uint32_t pointer, but the pointer is not guaranteed to be aligned, not even in practice.
* sub: fix undefined behavior in ASS color calculation (2)wm42014-05-101-2/+2
| | | | Same problem as previous commit, fix by using the MP_ASS_RGBA() macro.
* sub: fix undefined behavior in ASS color calculationwm42014-05-101-1/+1
| | | | | | | This might shift bits into the sign, which is undefined behavior. Making the right operand unsigned was supposed to help with this, but it seems it did nothing, and C99 makes the result type dependent on the left operand only.
* common: change MP_NOPTS_VALUE definitionwm42014-05-101-2/+2
| | | | | | | | | Use the exact floating point value, instead of a broken integer constant. The expression calculating the constant probably relied on undefined behavior, because it left-shifts a negative value. This also changes the type of the constant to double, which is perfectly fine, and maybe better than an integer constant.
* encode: fix PTS unit mismatchwm42014-05-102-11/+11
| | | | | | This used MP_NOPTS_VALUE to compare with ffmpeg-style int64_t PTS values. This probably happened to work, because both constants use the same value.
* vdpau: make mp_vdpau_ctx thread-safewm42014-05-102-21/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Preparation so that various things related to video can run in different threads. One part to this is making the video surface pool safe. Another issue is the preemption mechanism, which continues to give us endless pain. In theory, it's probably impossible to handle preemption 100% correctly and race-condition free, unless _every_ API user in the same process uses a central, shared mutex to protect every vdpau API call. Otherwise, it could happen that one thread recovering from preemption allocates a vdpau object, and then another thread (which hasn't recovered yet) happens to free the object for some reason. This is because objects are referenced by integer IDs, and vdpau will reuse IDs invalidated by preemption after preemption. Since this is unreasonable, we're as lazy as possible when it comes to handling preemption. We don't do any locking around the mp_vdpau_ctx fields that are normally immutable, and only can change when recovering from preemption. In practice, this will work, because it doesn't matter whether not-yet-recovered components use the old or new vdpau function pointers or device ID. Code calls mp_vdpau_handle_preemption() anyway to check for the preemption event and possibly to recover, and that function acquires the lock protecting the preemption state. Another possible source of potential grandiose fuckup is the fact that the vdpau library is in fact only a tiny wrapper, and the real driver lives in a shared object dlopen()ed by the wrapper. The wrapper also calls dlclose() on the loaded shared object in some situations. One possible danger is that failing to recreate a vdpau device could trigger a dlclose() call, and that glibc might unload it. Currently, glibc implements full unloading of shared objects on the last dlclose() call, and if that happens, calls to function pointers pointing into the shared object would obviously crash. Fortunately, it seems the existing vdpau wrapper won't trigger this case and never unloads the driver once it's successfully loaded. To make it short, vdpau preemption opens up endless depths of WTFs. Another issue is that any participating thread might do the preemption recovery (whichever comes first). This is easier to implement. The implication is that we need threadsafe xlib. We just hope and pray that this will actually work. This also means that once vdpau code is actually involved in a multithreaded scenario, we have to add XInitThreads() to the X11 code.
* vdpau: remove some codewm42014-05-101-7/+3
| | | | | There's no reason why we should treat the preemption case differently here.
* vo_vdpau, vo_opengl: handle vdpau preemption differentlywm42014-05-104-64/+29
| | | | | | | | | | | | | | | | | | | | Use the newly provided mp_vdpau_handle_preemption() function, instead of accessing mp_vdpau_ctx fields directly. Will probably make multithreaded access to the vdpau context easier. Mostly unrelated to the actual changes, I've noticed that using hw decoding with vo_opengl sometimes leads to segfaults inside of nvidia's libGL when doing the following: 1. use hw decoding + vo_opengl 2. switch to console (will preempt on nvidia systems) 3. switch back to X (mpv will recover, switches to sw decoding) 4. enable hw decoding again 5. exit mpv Then it segfaults when mpv finally calls exit(). I'll just blame nvidia, although it seems likely that something in the gl_hwdec_vdpau.c preemption handling triggers corner cases in nvidia's code.
* vdpau: handle display preemption during decodingwm42014-05-103-38/+39
| | | | | | | | | | | | This was broken for some time, and it didn't recover correctly. Redo decoder display preemption. Instead of trying to reinitialize the hw decoder, simply fallback to software decoding. I consider display preemption a bug in the vdpau API, so being able to _somehow_ recover playback is good enough. The approach taking here will probably also make it easier to handle multithreading.
* input: fix typos, cosmeticswm42014-05-101-10/+10
|
* w32_common: fix typowm42014-05-101-2/+3
| | | | Also, reset rc completely, instead of assuming things.
* osxbundle: split and optimize bundling scriptStefano Pigozzi2014-05-092-66/+94
| | | | | | | | | | | Move the code that copies the dylib's to the bundle to a new script (dylib-unhell.py) which is called by osxbundle.py. dylib-unhell is about 20x faster than the previous implementation. This is accomplished by removing superflous shell-out operations which are kept track of using an in memory tree of all the needed dependencies. Moreover the shell-outs have been further optimized by not requiring a complete shell for every operation and just using subprocess.call (which is equivalent to Popen).
* Merge pull request #774 from kevmitch/man_pdf_tweakskevmitch2014-05-091-20/+18
|\ | | | | man: tweak --sub-codepage for concision
| * man: tweak --sub-codepage for concisionKevin Mitchell2014-05-091-20/+18
|/