summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* command: mark get_property as deprecatedwm42015-02-132-3/+6
| | | | | Using it just makes no sense. But we're really being nice about this and don't remove it immediately.
* x11: make all XF86 special keys mappablewm42015-02-132-1/+13
| | | | | | | | Makes all keys documented in XF86keysym.h mappable. This requires the user to deal with numeric keycodes; no names are queried or exported. This is an easy way to avoid adding all the hundreds of XF86 keys to our X11 lookup table and mpv's keycode/name list.
* ipc: put playback core to sleep while dequeuing commandswm42015-02-131-1/+7
| | | | | | | Happens to fix #1581 due to an unfortunate interaction with the way the VO does not react to commands for a while if a video frame is queued. Slightly improves other situations as well, if the client spams mpv with commands during playback.
* demux: hack for instant stream switchingwm42015-02-135-4/+92
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This removes the delay when switching audio tracks in mkv or mp4 files. Other formats are not enabled, because it's not clear whether the demuxers fulfill the requirements listed in demux.h. (Many formats definitely do not with libavformat.) Background: The demuxer packet cache buffers a certain amount of packets. This includes only packets from selected streams. We discard packets from other streams for various reasons. This introduces a problem: switching to a different audio track introduces a delay. The delay is as big as the demuxer packet cache buffer, because while the file was read ahead to fill the packet buffer, the process of reading packets also discarded all packets from the previously not selected audio stream. Once the remaining packet buffer has been played, new audio packets are available and you hear audio again. We could probably just not discard packets from unselected streams. But this would require additional memory and CPU resources, and also it's hard to tell when packets from unused streams should be discarded (we don't want to keep them forever; it'd be a memory leak). We could also issue a player hr-seek to the current playback position, which would solve the problem in 1 line of code or so. But this can be rather slow. So what we do in this commit instead is: we just seek back to the position where our current packet buffer starts, and start demuxing from this position again. This way we can get the "past" packets for the newly selected stream. For streams which were already selected the packets are simply discarded until the previous position is reached again. That latter part is the hard part. We really want to skip packets exactly until the position where we left off previously, or we will skip packets or feed packets to the decoder twice. If we assume that the demuxer is deterministic (returns exactly the same packets after a seek to a previous position), then we can try to check whether it's the same packet as the one at the end of the packet buffer. If it is, we know that the packet after it is where we left off last time. Unfortunately, this is not very robust, and maybe it can't be made robust. Currently we use the demux_packet.pos field as unique packet ID - which works fine in some scenarios, but will break in arbitrary ways if the basic requirement to the demuxer (as listed in the demux.h additions) are broken. Thus, this is enabled only for the internal mkv demuxer and the libavformat mp4 demuxer. (libavformat mkv does not work, because the packet positions are not unique. Probably could be fixed upstream, but it's not clear whether it's a bug or a feature.)
* demux_mkv: return unique file positions for all packetswm42015-02-131-4/+5
| | | | | | | | | | | | | Until now, some packets could return the same file position if they were split off from a Matroska-level packet. This was perfectly fine, because the file position isn't used for anything overly important (it uses it to estimate playback position if no other information is available). The following commit will use the demux_packet.pos field as unique ID (as a simplification), so make the demuxer export more finegrained information. Also, the last_filepos field didn't have to be global, at least not anymore.
* vo_opengl: fix smoothmotion coefficient calculationStefano Pigozzi2015-02-133-7/+5
| | | | | Using prev_pts as the start of the scale was plain wrong. Change it to prev_vsync.
* cocoa: fix exiting the command line playerwm42015-02-131-4/+3
| | | | | | | | Commit e920a00eb assumed that terminate_cocoa_application() actually would exit. But apparently that is not always the case; e.g. mpv --help will just hang. The old code had a dummy exit(0), which was apparently actually called. Fix by explicitly exiting if mpv_main() returns and terminate_cocoa_application() does nothing.
* encoding: fixed-vo option was removedwm42015-02-131-1/+0
|
* player: add a --loop=force modewm42015-02-124-13/+17
| | | | | | | Requested. See manpage additions. This also makes the magical loop_times constants slightly saner, but shouldn't change the semantics of any existing --loop option values.
* osx: move code to unset input context to the right placewm42015-02-121-4/+4
| | | | | | | Setting the input context is always called, both in cplayer and libmpv, and under HAVE_COCOA. Unsetting the input context was done only the cplayer uninit call. Also it was under HAVE_COCOA_APPLICATION, so it was not unset in libmpv (dangling pointer).
* osx: move cocoa specific call out of common codewm42015-02-122-8/+2
| | | | This is almost equivalent, and gets rid of the ifdef.
* player: drop explicit exit() callswm42015-02-122-16/+11
| | | | | | | | | The code in main.c calls exit() explicitly, but the code is actually easier to follow by simply exiting from main() instead. The exit() call in av_log.c happens only on severely broken builds, so replace it with abort(). (Shuts up rpmlint warnings.)
* ao_pulse: listen for hotplug eventswm42015-02-121-7/+41
| | | | | | | | | | | | | | | This requires jumping through multiple hoops on fire. Since the PulseAudio API is virtually undocumented, I'm not sure if this is correct either. We only react to sink events, and only to the NEW/REMOVE events. CHANGE events are ignored, because PulseAudio fires them far too often - even if the system is completely idle! If pa_sink_info.name can change, we're in trouble. pa_sink_info.description is not so important, but it'd also be a bit un-nice if it can change, and we don't update it. The weird way how the actual AO and the hotplug context share the same struct (ao) comes in handy here, although context_success_cb() still had to be duplicated from success_cb() - the unused argument has a different type.
* audio: add device change notification for hotpluggingwm42015-02-128-33/+151
| | | | | | | | | | | | | | | | | | | | | | | | | | | Not very important for the command line player; but GUI applications will want to know about this. This only adds the internal API; support for specific audio outputs comes later. This reuses the ao struct as context for the hotplug event listener, similar to how the "old" device listing API did. This is probably a bit unclean and confusing. One argument got reusing it is that otherwise rewriting parts of ao_pulse would be required (because the PulseAudio API requires so damn much boilerplate). Another is that --ao-defaults is applied to the hotplug dummy ao struct, which automatically applies such defaults even to the hotplug context. Notification works through the property observation mechanism in the client API. The notification chain is a bit complicated: the AO notifies the player, which in turn notifies the clients, which in turn will actually retrieve the device list. (It still has the advantage that it's slightly cleaner, since the AO stuff doesn't need to know about client API issues.) The weird handling of atomic flags in ao.c is because we still don't require real atomics from the compiler. Otherwise we'd just use atomic bitwise operations.
* ao: set correct client name when listing deviceswm42015-02-121-4/+3
| | | | | | | | | | This is a small oversight. The client name (as set on command line options or, more importantly, the client API) was not set when listing devices e.g. via the "audio-device-list" property. Might or might not fix #1578. Also adjust the log level for an unrelated message.
* sd_ass: fix some corner cases in tag strippingwm42015-02-121-5/+14
| | | | This behavior is implied by VSFilter.
* Revert "player: make --force-window create the window immediately on start"wm42015-02-121-1/+0
| | | | | | | | | | | This reverts commit acc5e8f57419debdb74234a228b44db75023e28b. As expected, some didn't like this. Others won't like this revert. Whatever. See #1561. This should go into mpv 0.8.0 before it's released.
* player: use af_scaletempo when slowing down audio toowm42015-02-122-2/+2
| | | | | | In my opinion the artifacts created by af_scaletempo on extreme slowdown (50% or so) are too bothersome - but users disagree. So use af_scaletempo on any speed changes, not just on speedup.
* vf_lavfi: drop useless option from wrapper filterswm42015-02-121-4/+1
| | | | | | | Filters which merely wrap libavfilter (for user-compatibility) like vf_gradfun had a "lavfi-enable" suboption, which could disable libavfilter usage. Since none of these filters has an internal implementation anymore, this was completely useless.
* af_rubberband: actually fix deadlockMartin Herkt2015-02-121-1/+1
| | | | 371e5d0 missed this one
* af_rubberband: fix filter error deadlockwm42015-02-121-2/+2
| | | | | | | | | | | | rubberband_available() can return a negative value, which we assigned to a size_t variable, leading to the frame allocation to fail. This could spam "Error filtering frame.". (That it spams this instead of exiting should probably also be considered a bug.) At least in the realtime mode and in our case, a negative return value should not have any different meaning from a 0 return value, in particular because we call rubberband_get_samples_required() or set the "final" parameter for rubberband_process() to continue/stop processing.
* af_rubberband: change defaultsMartin Herkt2015-02-121-9/+6
| | | | | | | | | After some testing, I am fairly convinced that these defaults sound better than the previous settings. This also eliminates some issue with random crackling and noise. Also remove the `stretch` option since it has no effect in realtime mode.
* af_rubberband: fix breakagewm42015-02-111-1/+3
| | | | | | | | | The previous commit on this filter accidentally removed the RubberBandOptionProcessRealTime option. Without it, the lib prints a warning and passes the audio through. Also add the RubberBandOptionSmoothingOn option back. Though for some reason the output sounds still very wrong.
* video/filters: simplify libavfilter bridgewm42015-02-1113-71/+61
| | | | | | | | | | Remove the confusing crap that allowed a filter using the libavfilter bridge to be compiled without libavfilter. Instead, compile the wrappers only if libavfilter is enabled at compile time. The only filter which still requires it is vf_stereo3d (unfortunately). Special-case this one. (The whole filter and how it interacts with lavfi is pure braindeath anyway.)
* vf_noise: remove internal implementationwm42015-02-112-243/+8
| | | | | It requires libavfilter now, just like many other filters. Not sure if it even makes sense to keep this wrapper.
* af_rubberband: make all librubberband options configurablewm42015-02-112-4/+52
| | | | | | | librubberband exports a big load of options. Normally, the default settings (whether they're librubberband defaults or our defaults) should be sufficient, but since I'm not so sure about this, making it configurable allows others to figure it out for me.
* af_rubberband: attempt to fix audio position calculationwm42015-02-111-4/+17
| | | | | | | | | | | The problem here is that librubberband can buffer an arbitrary amount of data, but at the same time doesn't provide a way to query how much data is buffered. So we keep track of this manually, assuming that librubberband tries to reach the requested time ratio for input and output (which is probably true). The disadvantage is that rounding errors could accumulate over time. (Maybe it should try to round towards keeping the time ratio.)
* af_rubberband: always calculate and set delaywm42015-02-111-12/+11
| | | | Basically, add an if and reindent the block instead of exiting early.
* af: account for queued frames in audio position calculationwm42015-02-111-0/+2
| | | | af_rubberband exposed this issue.
* af_rubberband: improve EOF handlingwm42015-02-111-5/+11
| | | | | | In theory it could happen that draining on EOF happens incrementally, and then the unconditional reset could have dropped the remaining buffered audio.
* dvb_tune: fix invalid syntaxwm42015-02-111-1/+1
| | | | Oops.
* audio: fix pool allocationwm42015-02-111-1/+2
| | | | | It reallocated the pool on every request, making the pool completely useless. Oops.
* af_rubberband: pitch correction with librubberbandwm42015-02-117-0/+187
| | | | | | | | | If "--af=rubberband" is used, librubberband will be used to speed up or slow down audio with pitch correction. This still has some problems: the audio delay is not calculated correctly, so the audio position jitters around by a few milliseconds. This will probably ruin video timing.
* player: skip audio filter reinit on some types of speed changeswm42015-02-101-1/+11
| | | | | | | | | | | | | This avoids potentially dropping some small amount of audio data buffered in filters. Reinit can be skipped only if the filter is af_scaletempo (which maps to AF_CONTROL_SET_PLAYBACK_SPEED). The other case using af_lavrresample is much more complicated due to filter chain politics. Also, changing speed between 1.0 and something higher typically inserts or removes the filter, so this obviously requires reinitialization. It can be prevented by forcing the filter with --af=scaletempo.
* af_scaletempo: allow changing speed at runtime without reinitwm42015-02-101-18/+21
| | | | | | | | | | | | | | | | Staring at the code a bit, it turns out that changing speed without losing state is quite easy. The initialization code is big and complicated, but most of it is specific only to the configured audio format, not the speed. Refactor the code so that changing speed at runtime could work. (It's not actually used yet - the player code still does a complete reinit. This will be fixed in the next commit.) The "if (s->speed_tempo == s->speed_pitch)" looks a bit strange, but does the same thing as the code did before: speed can be changed only if exactly one flag is set. If both are set or none, speed can't be changed.
* af_scaletempo: drop detaching or skipping init on speed=1wm42015-02-101-7/+5
| | | | | | | | | | | | | | | | | | This code skipped initialization if no speed/pitch change was to be applied. It also didn't force conversion of the audio to a supported format, which is probably the most important case in context of compatibility. With this change applied, af_scaletempo will always force format conversion. To make the change less disruptive, make the filter detach if unconvertable formats are used. Some users use spdif and also have "af=scaletempo" in their config, so better not completely break this. In the case the filter was added with the "speed=both" suboption, the filter also detached itself in this case; but it's an obscure case, so I don't care about that.
* manpage: fix af_scaletempo suggested commandswm42015-02-101-3/+3
|
* manpage: ipc: suggest --idlewm42015-02-091-1/+2
|
* win32: fix/change application namewm42015-02-092-3/+3
| | | | Pointed out in #935 (again).
* README: mention some more depswm42015-02-091-0/+2
|
* README: movie -> mediawm42015-02-081-1/+1
| | | | Requested in #935.
* vo: minor simplificationwm42015-02-071-13/+8
| | | | Whatever.
* vo_vdpau: minor simplificationwm42015-02-071-4/+1
| | | | No change in behavior.
* Revert "vo_opengl: disable alpha by default"wm42015-02-062-3/+3
| | | | | | | | | | This reverts commit a33b46194c3525cb585cc78b449ec275dbfd7f83. It turns out FFmpeg really considers this a bug, and fixed it by making the decoder output the correct pixel format. Fixes #1565. Reverts the fix #1528, though it should work fine with a recent git master FFmpeg.
* video: work around libswscale for PNG pixel formatswm42015-02-064-5/+45
| | | | | | | | The intention is that we can test vo_opengl with high bit depth PNGs better. This throws libswscale completely out of the loop, which before was needed in order to convert from big endian to little endian. Also apply a minimal cleanup to fmt-conversion.c (unrelated).
* stream: get rid of remaining uses of the end_pos fieldwm42015-02-067-26/+25
| | | | | | | | Most things stopped using this field for better support of growing files. Go through the trouble to repalce the remaining uses, so it can be removed. Also move the "streaming" field; saves 4 bytes (wow!).
* stream: minor cleanupswm42015-02-064-88/+64
| | | | | | | | | | | | | | | | Fix return types and return values to make them more consistent. Some reformatting and making code more concise. In stream_reconnect(), avoid the additional mp_cancel_test() call by moving the "connection lost" message below the mp_cancel_wait() call, which effectively leads to the same behavior when the stream was already canceled. (The goal is not to show the message in this case.) Merge stream_seek_long() into stream_seek(). It was the only caller. Always clear the eof flag on seeks. Reduce access to stream internals in cache.c and stream_lavf.c.
* stream: slightly improve reconnect behaviorwm42015-02-062-18/+29
| | | | | Wait for a longer time between reconnects. Introdeuce and use mp_cancel_wait(), so that quitting is still immediate.
* stream_lavf: fix build with Libavwm42015-02-061-2/+5
| | | | | | The API function used is FFmpeg-only. Sigh...
* options: add --network-timeoutwm42015-02-064-0/+11
| | | | | | Not quite sure if this actually works as intended. Fixes #1566.
* options: change --msg-level optionwm42015-02-067-93/+89
| | | | | | | | | | | | | | Make it accept "," as separator, instead of only ":". Do this by using the key-value-list parser. Before this, the option was stored as a string, with the option parser verifying that the option value as correct. Now it's stored pre-parsed, although the log levels still require separate verification and parsing-on-use to some degree (which is why the msg-level option type doesn't go away). Because the internal type changes, the client API "native" type also changes. This could be prevented with some more effort, but I don't think it's worth it - if MPV_FORMAT_STRING is used, it still works the same, just with a different separator on read accesses.
* options: allow ":" as separator in key-value listswm42015-02-061-1/+1
| | | | | | | | Before this, unquoted occurrences of ":" lead to parsing errors. There's no reason to reject it, especially since the traditional MPlayer syntax uses ":" as separator. (Which is also the reason why ":" was rejected before: the parser shares this code for handling splitting/quoting, and we merely checked explicitly whether the option was split on ",".)
* tl_matroska: only check the chapter count when adding chaptersBen Boeckel2015-02-061-3/+3
| | | | | | | Fixes #1445 without failing in the case where file outside.mkv with N chapters references inside.mkv with N+1 chapters. Since we don't care about the number of chapters in inner files (yet; nested chapters would change this, but also make chapters dynamic anyways), don't check there.
* tl_matroska: squeeze down the number of parametersBen Boeckel2015-02-061-62/+77
| | | | | | Much cleaner. The difference between timeline_info and inner_timeline_info is that timeline_info is stuff the top-level cares about and inner_timeline_info is just for the current chapter.
* vo_opengl: add support for linear scaling without CMSNiklas Haas2015-02-064-23/+41
| | | | | | | | | | This introduces a new option linear-scaling, which is now implied by srgb, icc-profile and sigmoid-upscaling. Notably, this means (sigmoidized) linear upscaling is now enabled by default in opengl-hq mode. The impact should be negligible, and there has been no observation of negative side effects of sigmoidized scaling, so it feels safe to do so.
* vo_opengl: get rid of unused field approx_gammaNiklas Haas2015-02-061-1/+0
| | | | This was left over from 61f5a80.
* player: do not autoload audio with audio files, enable autoloadingwm42015-02-053-4/+16
| | | | | | | | | | | | | | Autoload external audio files only if there's at least a video track (which is not coverart pseudo-video). Enable external audio file autoloading by default. Now that we actively avoid doing stupid things like loading an external audio file for an audio-only file, this should be fine. Additionally, don't autoload subtitles if a subtitle is played. Although you currently can't play subtitles without audio or video, it's disturbing and stupid that t