summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* options: add options that set defaults for af/vf/ao/vowm42013-12-0113-8/+69
| | | | | | | | There are some use cases for this. For example, you can use it to set defaults of automatically inserted filters (like af_lavrresample). It's also useful if you have a non-trivial VO configuration, and want to use --vo to quickly change between the drivers without repeating the whole configuration in the --vo argument.
* old-configure: delete pre-waf config.h and config.makwm42013-11-301-0/+4
|
* osdep/io: also include unistd.hwm42013-11-301-0/+2
| | | | Might be needed by fcntl() usage.
* Prevent creating zombieswm42013-11-301-3/+14
| | | | | | | | | | | | | | | | The "run" input command does fork+exec to spawn child processes. But it doesn't cleanup the child processes, so they are left as zombies until mpv terminates. Leaving zombie processes around is not very nice, so employ a simple trick to let pid 1 take care of this: we fork twice, and when the first fork exits, the second fork becomes orphaned and becomes pid 1's child. It becomes pid 1's responsibility to cleanup the process. The advantage is that we don't need extra logic to cleanup the spawned process, which could have an arbitrary lifetime. This is e.g. described here: http://yarchive.net/comp/zombie_process.html Also use _exit() instead of exit(). It's not really sane to run cleanup handlers (atexit() etc.) inside a forked process.
* Use O_CLOEXEC when creating FDswm42013-11-3015-30/+81
| | | | | | | | | | | | | | This is needed so that new processes (created with fork+exec) don't inherit open files, which can be important for a number of reasons. Since O_CLOEXEC is relatively new (POSIX.1-2008, before that Linux specific), we #define it to 0 in io.h to prevent compilation errors on older/crappy systems. At least this is the plan. input.c creates a pipe. For that, add a mp_set_cloexec() function (which is based on Weston's code in vo_wayland.c, but more correct). We could use pipe2() instead, but that is Linux specific. Technically, we have a race condition, but it won't matter.
* build: don't check libsmbclient version numberwm42013-11-301-1/+1
| | | | Rationale see github issues #385. Fixes #385.
* ao_oss: add 6.1 and 7.1 speaker placement from FreeBSDbugmen0t2013-11-301-1/+15
|
* ao_oss: SNDCTL_DSP_CHANNELS takes int, not uint8_twm42013-11-301-2/+3
| | | | | | | This caused weird issue, probably caused by setting up the wrong number of channels, or similar. See github issue #383. Patch by bugmen0t on github.
* ao_alsa: remove unneeded checkswm42013-11-301-19/+11
| | | | | If initialization succeeds, p->alsa should always be set. Additional checks are not needed, and also this wasn't even done consistently.
* ao_alsa: enable "plug" for non-interleaved float formats toowm42013-11-301-2/+1
| | | | | | I have no idea what this code does, but it seems logical it should be active for all float formats, not just for float with interleaved access.
* command: add a cycle_values input commandwm42013-11-304-1/+102
|
* command: change the syntax and semantics of the "run" commandwm42013-11-303-9/+38
| | | | | | | See the changes in input.rst for explanations. Technically speaking, this also gets rid of some undefined behavior: passing NULL as a vararg (execl()) is always a bug.
* input: require space before '#' commentswm42013-11-301-8/+5
| | | | | | | | | | So e.g. show_text abc#def will now print "abc#def" instead of "#def". It's simpler, more consistent with how ";" and other things are handled, and also possibly avoids bothering the user with extra escaping.
* input: rearrange command parsingwm42013-11-301-44/+31
| | | | This simplifies some things as preparation for the next commits.
* build: make deps_neg work with multiple dependenciesStefano Pigozzi2013-11-291-2/+2
| | | | Previous code only worked id len(deps_neg) was 1.
* build: reimplement the OSS checks using a more declarative approachStefano Pigozzi2013-11-295-69/+55
| | | | | | | | | | | | | | | | | | The OSS checks were a big mess and quite buggy. This reimplementes them using a declarative approach and clearly distinguishing between the various OSS implementations. The code should now almost be auto-documenting. We currently support the following implementations of OSS: * platform-specific (with `sys/soundcard.h`) * SunAudio (default on NetBSD and useable on OpenBSD even if we have sndio support there). * 4Front (default on FreeBSD) Since now each OSS check also checks for the appropriate soundcard header, remove the old soundcard check. Many thanks to @bugmen0t for in depth info about all the BSDs. Check #380 and #359 for more info on this commit.
* build: add options for enabling and disabling any libquvi versionsNikoli2013-11-293-10/+13
| | | | Makes packaging a bit simpler.
* Take care of some libavutil deprecations, drop support for FFmpeg 1.0wm42013-11-2912-164/+162
| | | | | | | | | | | | | | PIX_FMT_* -> AV_PIX_FMT_* (except some pixdesc constants) enum PixelFormat -> enum AVPixelFormat Losen some version checks in certain newer pixel formats. av_pix_fmt_descriptors -> av_pix_fmt_desc_get This removes support for FFmpeg 1.0.x, which is even older than Libav 9.x. Support for it probably was already broken, and its libswresample was rejected by our build system anyway because it's broken. Mostly untested; it does compile with Libav 9.9.
* ao_alsa: disable ALSA resampling by default againwm42013-11-292-1/+13
| | | | | | | | | | | | | | | | | | | | | This partially reverts commit 7d152965. It turns out that at least some ALSA drivers (at least snd-hda-intel) report incorrect audio delay with non-native sample rates, even if the sample rate is only very slightly different from the native one. For example, 48000Hz is fine on my hda-intel system, while both 8000Hz and 47999Hz lead to a delay off by 40ms (according to mpv's A/V difference display), which suggests that something in ALSA is calculating the delay using the wrong sample rate. As an additional problem, with ALSA resampling enabled, using 48001Hz/float/2ch fails, while 49000Hz/float/2ch or 48001Hz/s16/2ch work. With resampling disabled, all these cases work obviously, because our own resampler doesn't just refuse any of these formats. Since some people want to use the ALSA resampler (because it's highly configurable, supports multiple backends, etc.), we still allow enabling ALSA resampling with an ao_alsa suboption.
* player: always reset some variables on seekwm42013-11-291-4/+4
| | | | | | These were confined to the video path, but resetting them even if no video is available shouldn't really matter. Always resetting them makes the logic easier to follow, I think.
* vf_pullup: properly reset on seekwm42013-11-291-14/+37
| | | | | | | Sometimes, vf_pullup hanged on seek. This was because it never was properly reset. Old timestamps messed up the timestamp calculations, which made the player show frames for a ridiculously long time, which is perceived as pausing or hanging.
* video: restore printing warning on decreasing filter PTSwm42013-11-291-2/+2
| | | | | | | | Recently, the check was moved, so it was printed only for source video PTS (since that's easier, and filters should normally behave sane). But it turns out it's trivial to print a warning in the filter case too by reusing the code that normally checks for PTS forward jumps without needing any additional code, so, fine, restore warning in this case.
* gl_hwdec: use a imgfmt field instead of a query_format callbackwm42013-11-294-15/+5
| | | | | Now that vdpau always uses a single image format, this can be simplified.
* vdpau: always let decoder output IMGFMT_VDPAUwm42013-11-293-3/+4
| | | | | | | | | | The old ffmpeg vdpau support code uses separate vdpau pixel formats for each decoder (pretty much because mplayer's architecture sucked), which just gets into the way. Force the old decoder's output to IMGFMT_VDPAU, and remove IMGFMT_IS_VDPAU() where we can remove it. This should completely remove the differences betwene the old and new vdpau decoder outside of the decoder.
* vaapi: remove unused hw image formats, simplifywm42013-11-297-26/+11
| | | | | | | | | | PIX_FMT_VDA_VLD and PIX_FMT_VAAPI_VLD were never used anywhere. I'm not sure why they were even added, and they sound like they are just for compatibility with XvMC-style decoding, which sucks anyway. Now that there's only a single vaapi format, remove the IMGFMT_IS_VAAPI() macro. Also get rid of IMGFMT_IS_VDA(), which was unused.
* build: make pthreads mandatorywm42013-11-2810-56/+17
| | | | | | | | | | | pthreads should be available anywhere. Even if not, for environment without threads a pthread wrapper could be provided that can't actually start threads, thus disabling features that require threads. Make pthreads mandatory in order to simplify build dependencies and to reduce ifdeffery. (Admittedly, there wasn't much complexity, but maybe we will use pthreads more in the future, and then it'd become a real bother.)
* command: allow "current" as argument to playlist_remove commandwm42013-11-283-3/+10
| | | | Feature request from github issue #376.
* input: use separate type for command definitionswm42013-11-284-54/+79
| | | | | | | | | | | | | Introduce a mp_cmd_def struct to define commands, instead of using mp_cmd for this. This way each command parameter can be a m_option, instead of m_option plus some more stuff. Define the ARG_ macros directly in terms of the OPT_ macros. Not sure if this makes it easier to read (maybe not, even if it looks simpler), but at least it makes it easier to add other option types. Another idea was adding a name for each parameter (so you could have named parameters), but not today.
* player: simple hack to make backstep code somewhat more robustwm42013-11-281-3/+12
| | | | | | | | | | | | | | | | | | | The hr-seek code assumes that when seeking the demuxer, the first image decoded after the seek will have a PTS exactly equal to the demuxer seek target time, or before that target time. Incorrect timestamps, implicitly dropped initial frames, or broken files/demuxers can all break this assumption, and lead to hr-seek missing the seek target. Generally, this is not much a problem (the user won't notice being off by one frame), but it really shows when using the backstep feature. In this case, backstepping would simply hang. Add a simple hack that basically forces a minimal value for the --hr- seek-demuxer-offset option (which is 0 by default) when doing a backstep-seek. The chosen minimum value is arbitrary. There's no perfect value, though in general it should perhaps be slightly longer than the frametime, which the chosen value is more than enough for typical framerates.
* video: add insane hack to work around FFmpeg/Libav insanitywm42013-11-284-3/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | So, FFmpeg/Libav requires us to figure out video timestamps ourselves (see last 10 commits or so), but the methods it provides for this aren't even sufficient. In particular, everything that uses AVI-style DTS (avi, vfw-muxed mkv, possibly mpeg4-in-ogm) with a codec that has an internal frame delay is broken. In this case, libavcodec will shift the packet- to-image correspondence by the codec delay, meaning that with a delay=1, the first AVFrame.pkt_dts is not 0, but that of the second packet. All timestamps will appear shifted. The start time (e.g. the time displayed when doing "mpv file.avi --pause") will not be exactly 0. (According to Libav developers, this is how it's supposed to work; just that the first DTS values are normally negative with formats that use DTS "properly". Who cares if it doesn't work at all with very common video formats? There's no indication that they'll fix this soon, either. An elegant workaround is missing too.) Add a hack to re-enable the old PTS code for AVI and vfw-muxed MKV. Since these timestamps are not reorderd, we wouldn't need to sort them, but it's less code this way (and possibly more robust, should a demuxer unexpectedly output PTS). The original intention of all the timestamp changes recently was actually to get rid of demuxer-specific hacks and the old timestamp sorting code, but it looks like this didn't work out. Yet another case where trying to replace native MPlayer functionality with FFmpeg/Libav led to disadvantages and bugs. (Note that the old PTS sorting code doesn't and can't handle frame dropping correctly, though.) Bug reports: https://trac.ffmpeg.org/ticket/3178 https://bugzilla.libav.org/show_bug.cgi?id=600
* video: warn against non-monotonic PTS instead of decreasing PTSwm42013-11-281-2/+2
| | | | And by non-monotonic, we mean "strictly non-monotonic".
* video: add heuristic to prevent framedrop during hrseek if pts brokenwm42013-11-283-1/+13
| | | | | | | | | | | | | | | | | | | | | | | Using --start with files that use DTS only, or which simply have broken PTS timestamps, would incorrectly drop frames and possibly not execute the seek correctly. Add yet another heuristic to detect this. The intent is that --start and hr-seeks in general should work correctly, but in order to keep things fast, we still want to allow frame dropping during hr-seek if there are no problems doing so. Do this by disabling frame dropping by default, but re-enabling it if there are no problems found for a while. As a consequence, --start might be somewhat slower, but normal user interaction should remain as fast as before. Note that there's something subtle about the added code: the has_broken_packet_pts field is checked even before the first packet is fed to dec_video.c, so the field must not be set to 0 right on start. It's not initially set to 0 anyway, because the heuristic requires decoding some images before enabling frame drop anyway. Note 2: it's not clear whether frame dropping during hr-seek really helps; I didn't benchmark it.
* build: make --disable-gl disable all the gl backendsStefano Pigozzi2013-11-283-4/+22
| | | | Fixes #369
* build: add custom -I/-L flags for the BSDs [2]Stefano Pigozzi2013-11-281-4/+4
| | | | Fixup commit. .append() seems to to nothing.
* ao_coreaudio: simplify ch label to speaker id conversionStefano Pigozzi2013-11-271-23/+37
| | | | | | | | Previous code was using the values of the AudioChannelLabel enum directly to create the channel bitmap. While this was quite smart it was pretty unreadable and fragile (what if Apple changes the values of those enums?). Change it to use a 'dumb' conversion table.
* build: add custom -I/-L flags for the BSDsStefano Pigozzi2013-11-271-0/+8
| | | | Apparently this is needed for stuff like iconv.
* old-build: fix iconv check on openbsdStefano Pigozzi2013-11-271-1/+1
|
* af_lavi: actually free the filter graph on uninitwm42013-11-271-5/+1
| | | | | | | This was a memory leak. Also remove the AF_CONTROL_COMMAND_LINE code, which was inactive. (It's never called if the new option parser is used.)
* video: replace d_video->pts field, change PTS jump checkswm42013-11-276-31/+24
| | | | | | | | | | | | | The d_video->pts field was a bit strange. The code overwrote it multiple times (on decoding, on filtering, then once again...), and it wasn't really clear what purpose this field had exactly. Replace it with the mpctx->video_next_pts field, which is relatively unambiguous. Move the decreasing PTS check to dec_video.c. This means it acts on decoder output, not on filter output. (Just like in the previous commit, assume the filter chain is sane.) Drop the jitter vs. reset semantics; the dec_video.c determined PTS never goes backwards, and demuxer timestamps don't "jitter".
* video: if PTS is missing, make something up using the frameratewm42013-11-272-10/+7
| | | | | | Also get rid of the PTS check _after_ filters. This means if there's a video filter which unsets PTS, no warning will be printed. But we assume that all filters are well-behaved enough by now.
* video: refactor PTS code, add fall back heuristic to DTSwm42013-11-275-76/+117
| | | | | | | | | | | | | | | | | | | | | | | | | | Refactor the PTS handling code to make it cleaner, and to separate the bits that use PTS sorting. Add a heuristic to fall back to DTS if the PTS us non-monotonic. This code is based on what FFmpeg/Libav use for ffplay/avplay and also best_effort_timestamp (which is only in FFmpeg). Basically, this 1. just uses the DTS if PTS is unset, and 2. ignores PTS entirely if PTS is non- monotonic, but DTS is sorted. The code is pretty much the same as in Libav [1]. I'm not sure if all of it is really needed, or if it does more than what the paragraph above mentions. But maybe it's fine to cargo-cult this. This heuristic fixes playback of mpeg4 in ogm, which returns packets with PTS==DTS, even though the PTS timestamps should follow codec reordering. This is probably a libavformat demuxer bug, but good luck trying to fix it. The way vd_lavc.c returns the frame PTS and DTS to dec_video.c is a bit inelegant, but maybe better than trying to mess the PTS back into the decoder callback again. [1] https://git.libav.org/?p=libav.git;a=blob;f=cmdutils.c;h=3f1c667075724c5cde69d840ed5ed7d992898334;hb=fa515c2088e1d082d45741bbd5c05e13b0500804#l1431
* Move some code from player to audio/video reset functionswm42013-11-274-13/+13
|
* cosmetics: rename video/audio reset functionswm42013-11-2711-21/+21
| | | | | | | | | | These used the suffix _resync_stream, which is a bit misleading. Nothing gets "resynchronized", they really just reset state. (Some audio decoders actually used to "resync" by reading packets for resuming playback, but that's not the case anymore.) Also move the function in dec_video.c to the top of the file.
* video: remove commented codewm42013-11-271-13/+2
|
* video: use dts as fallback when determining pts by sortingwm42013-11-271-11/+10
| | | | | This makes the new code equivalent with the old one, which often passed dts as pts. Also rename some variables to clear up things.
* ao_coreaudio: map channel labels needed for 8ch layoutsStefano Pigozzi2013-11-271-4/+30
| | | | | | The code stopped at kAudioChannelLabel_TopBackRight and missed mapping for 5 more channel labels. These are in a completely different order that the mpv ones so they must be mapped manually.
* audio: better rejection of invalid formatswm42013-11-274-20/+28
| | | | | | | | | This includes the case when lavc decodes audio with more than 8 channels, which our audio chain currently does not support. the changes in ad_lavc.c are just simplifications. The code tried to avoid overriding global parameters if it found something invalid, but that is not needed anymore.
* video/filter: fix PIC compile on x86Natanael Copa2013-11-262-3/+9
| | | | | | | | | | | | | When using PIC on x86 (eg with hardened toolchains) the ebx register is reserverd and cannot be used in assembly code. For vf_eq we allow the compiler to use memory as input. For vf_noise we temoporarily borrow the ebp register. This fixes #361. Signed-off-by: Natanael Copa <ncopa@alpinelinux.org>
* video: unbreak --no-correct-pts with demuxers that use DTSwm42013-11-264-6/+8
|
* demux_mkv: fix realvideo timestamp handlingwm42013-11-261-47/+40
| | | | | | | | | | | | | | | | | | | This was broken by the recent commits. Apparently realvideo timestamps are severely mangled, and Matroska _of course_ doesn't have the sane, umangled timestamps, but something unusable. The existing unmangling code in demux_mkv.c didn't output proper timestamps either. Instead, it was something weird that triggered sorting. Without sorting (it was disabled by default recently), you'd get decreasing PTS warnings In order to fix this, steal some code from libavcodec. Basically copy the contents of rv34_parser.c (with some changes), which makes everything magically work. (Maybe it would be better to use the libavcodec parser API, but I don't want to do that just for this. An alternative idea would be refusing to read files that have realvideo tracks, and delegate this to demux_lavf.c, but maybe that's too redical too.) I wish I hadn't notice this...
* bootstrap.py: reindent to 4 spacesStefano Pigozzi2013-11-261-4/+4
|
* build: remove pointless exception handling in oss checkStefano Pigozzi2013-11-261-9/+5
|
* build: unbreak __get_osslibdir__ on python3Stefano Pigozzi2013-11-261-1/+1
| | | | Fixes #370
* cocoa: unlock on uninitStefano Pigozzi2013-11-261-1/+3
| | | | NSLock should be unlocked before dealloc is called on it.
* build: check for pthreads with and without additional cflagsStefano Pigozzi2013-11-261-1/+5
|
* av_common: fix typo in commentStefano Pigozzi2013-11-261-1/+1
|
* ao_alsa: do not forcibly disable ALSA resamplingMartin Herkt2013-11-261-6/+0
| | | | | | | | Resampling with non-ancient ALSA setups works fine, so there is no need to keep this around. Furthermore, as of writing, the default builtin resampler used by many ALSA setups (taken from libspeex) actually has higher quality than the default resampling modes of avresample and swresample.
* ad_lavc: increase number of packets for initial decodewm42013-11-261-2/+5
| | | | | | | | | | | Apparently just 5 packets is not enough for the initial audio decode (which is needed to find the format). The old code (before the recent refactor) appeared to use 5 packets, but there were apparently other code paths which in the end amounted to more than 5 packets being read. The sample that failed (see github issue #368) needed 9 packets. Fixes #368.
* player: don't use a loop when no loop is neededwm42013-11-261-4/+1
| | | | | This used a really weird idiom: a loop that iterates only once, so you can use break; to jump out of the block.
* player: move code for skipping 0-sized video packets to demuxerwm42013-11-262-10/+9
| | | | | | | | | | These packets have to be explicitly dropped, because usually libavcodec uses 0-