summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* Release 0.19.0v0.19.0Martin Herkt2016-08-154-3/+112
|
* Merge branch 'master' into release/currentMartin Herkt2016-08-15142-1626/+2355
|\
| * vo_direct3d: add missing headerPaul B Mahol2016-08-141-0/+1
| | | | | | | | | | | | Fixes build under cygwin. Signed-off-by: wm4 <wm4@nowhere>
| * sub: don't potentially discard too many subtitles on seekwm42016-08-143-3/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The accepts_packet packet callback is supposed to deal with subtitle decoders which have only a small queue of current subtitle events (i.e. sd_lavc.c), in case feeding it too many packets would discard events that are still needed. Normally, the number of subtitles that need to be preserved is estimated by the rendering pts (get_bitmaps() argument). Rendering lags behind decoding, so normally the rendering pts is smaller than the next video frame pts, and we simply discard all subtitle events until the rendering pts. This breaks down in some annoying corner cases. One of them is seeking backwards: the VO will still try to render the old PTS during seeks, which passes a high PTS to the subtitle renderer, which in turn would discard more subtitles than it should. There is a similar issue with forward seeks. Add hacks to deal with those issues. There should be a better way to deal with the essentially unknown "rendering position", which is made worse by screenshots or rendering with vf_sub. At the very least, we could handle seeks better, and e.g. either force the VO not to re-render subs after seeks (ugly), or introduce seek sequence numbers to distinguish attempts to render earlier subtitles when a seek is done.
| * command: add replaygain information properties to track-listwm42016-08-132-0/+26
| |
| * demux: minor cleanup to replaygain error handlingwm42016-08-131-12/+9
| | | | | | | | | | | | | | If the PEAK tag is invalid, return an error. Make the error signalling conventions more uniform by strictly returning a negative value on error, and treating >=0 as success.
| * demux: make ALBUM replaygain tags optionalwm42016-08-131-3/+7
| | | | | | | | IF they're missing, use the TRACK ones instead. See #3405.
| * audio: log replaygain values in af_volume instead demuxerwm42016-08-132-12/+11
| | | | | | | | | | | | | | The demuxer layer usually doesn't log per-stream information, and even the replaygain information was logged only if it came from tags. So log it in af_volume instead.
| * demux: add per-track metadatawm42016-08-125-59/+143
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ...and ignore it. The main purpose is for retrieving per-track replaygain tags. Other than that per-track tags are not used or accessed by the playback core yet. The demuxer infrastructure is still not really good with that whole synchronization thing (at least in part due to being inherited from mplayer's single-threaded architecture). A convoluted mechanism is needed to transport the tags from demuxer thread to user thread. Two factors contribute to the complexity: tags can change during playback, and tracks (i.e. struct sh_stream) are not duplicated per thread. In particular, we update the way replaygain tags are retrieved. We first try to use per-track tags (common in Matroska) and global tags (effectively formats like mp3). This part fixes #3405.
| * audio/filter: remove delay audio filterPaul B Mahol2016-08-124-225/+0
| | | | | | | | Similar filter is available in libavfilter.
| * github: encourage providing sample fileswm42016-08-111-2/+6
| | | | | | | | | | Also, try to save users from trying to use the github file upload function. While we're at it, also make the sprunge.us hint a link.
| * command: add a property that returns filename without extensionwm42016-08-112-1/+19
| | | | | | | | Requested. Fixes #3404.
| * manpage: remove the word "slave"wm42016-08-111-6/+6
| | | | | | | | It's discriminatory or something.
| * stream/stream_bluray: display list of available titles on verboseRicardo Constantino2016-08-111-0/+6
| | | | | | | | Based on similar code on FFmpeg and libbluray's list_titles example.
| * player: add --no-autoload-files optionwm42016-08-104-0/+19
| | | | | | | | Allt his auto-loading is getting annoying especially for testing.
| * ao_alsa: make pause state more robust, reduce minor code duplicationwm42016-08-091-22/+25
| | | | | | | | | | | | | | | | | | With the previous commit, ao_alsa.c now has 3 possible ways to pause playback. Actually all 3 of them need get_delay() to fake its return value, so don't duplicate that code. Also much of the code looks a bit questionable when considering inconsistent pause/resume calls from outside, so ignore redundant calls.
| * ao_alsa: handle --audio-stream-silencewm42016-08-091-9/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | push.c does not handle this automatically, and AOs using push.c have to handle it themselves. Also, ALSA is low-level enough that it needs explicit support in user code. At least I haven't found any option that does this. We still can get away relatively cheaply by abusing underflow-handling for this. ao_alsa.c already configures ALSA to handle underflows by playing silence. So we purposely induce an underflow when opening the device, as well as when pausing or resetting the device. This introduces minor misbehavior: it doesn't account for the additional delay the initial silence adds, unless the device has fully played the fragment of silence when the player starts sending data to it. But nobody cares.
| * player: add --audio-wait-open optionswm42016-08-095-0/+20
| | | | | | | | Complements the option added in the previous commit.
| * player: add --audio-stream-silencewm42016-08-098-2/+27
| | | | | | | | | | Completely insane that this has to be done. Crap for compensating HDMI crap.
| * ao_coreaudio: actually use stop callbackwm42016-08-092-2/+2
| | | | | | | | | | | | The .pause callback is never used for pull.c-based AOs. This means this always streamed silence instead of deactivating audio.
| * af_lavcac3enc: allow passing options to libavcodecwm42016-08-091-0/+7
| |
| * wscript: improve stdatomic checkThomas Petazzoni2016-08-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current stdatomic check verifies the availability of the function by calling atomic_load(). It also uses this test to check if linking against libatomic is needed or not. Unfortunately, on specific architectures (namely SPARC), using atomic_load() does *not* require linking against libatomic, while other atomic operations do. Due to this, mpv's wscript concludes that stdatomic is available, and that linking against libatomic is not needed, causing the following link failure: [190/190] Linking build/mpv audio/out/ao.c.13.o: In function `ao_query_and_reset_events': /home/peko/autobuild/instance-0/output/build/mpv-0.18.1/build/../audio/out/ao.c:399: undefined reference to `__atomic_fetch_and_4' In order to fix this, the stdatomic check is adjusted to call atomic_fetch_add() instead, which does require libatomic. Thanks to this, the wscript realizes that linking against libatomic is needed, and the build works fine. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
| * stream: fix double-free if cache init failswm42016-08-081-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | If the normal stream cache init fails, and a file cache was initialized before, we free the file cache as well. But since the file cache is chained to the real stream, the real stream will also be freed. This has to be prevented by clearing the pointer to the original stream in the uncached_stream field. This could in particular be triggered by using --cache-initial=1000 and aborting playback during loading. (Without that option, stream cache init failure is far less likely.)
| * demux: do not add packets between refresh seek requested and donewm42016-08-081-1/+1
| | | | | | | | | | Could cause strange issues on seeks or track switches, was only visible as race condition.
| * stream_cb: fix stale commentwm42016-08-081-1/+1
| | | | | | | | Oops.
| * DOCS/release-policy.md: reminder to update certain version numberswm42016-08-071-1/+2
| |
| * client API: bump API for stream_cbwm42016-08-072-2/+4
| | | | | | | | | | | | | | | | | | Forgotten in previous commit. Also minor semi-related change: remove the extra "," from the mpv_sub_api enum, which I accidentally added in the previous commit. (C99 is fine with trailing ",", C89 strictly speaking not. So do this for maximum compatibility.)
| * client API: add stream_cb API for user-defined stream implementationsAman Gupta2016-08-079-3/+428
| | | | | | | | | | | | Based on #2630. Some heavy changes by committer. Signed-off-by: wm4 <wm4@nowhere>
| * client API: fix indentationwm42016-08-071-1/+1
| |
| * client API: add MPV_ERROR_GENERICwm42016-08-072-1/+6
| | | | | | | | Because why not.
| * w32_common: update window size on resize eventswm42016-08-071-0/+6
| | | | | | | | | | | | Fixes a regression introduced by commit 088a0075. Fixes #3400.
| * player: gross hack to improve non-hr seeking with external audio trackswm42016-08-073-0/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Relative seeks backwards with external audio tracks does not always work well: it tends to happen that video seek back further than audio, so audio will remain silent until the audio's after-seek position is reached. This happens because we strictly seek both video and audio demuxer to the approximate desirted target PTS, and then start decoding from that. Commit 81358380 removes an older method that was supposed to deal with this. It was sort of bad, because it could lead to the playback core freezing by waiting on network. Ideally, the demuxer layer would probably somehow deal with such seeks, and do them in a way the audio is seeked after video. Currently this is infeasible, because the demuxer layer assumes a single demuxer, and external tracks simply use separate demuxer layers. (MPlayer actually had a pseudo-demuxer that joined external tracks into a single demuxer, but this is not flexible enough - and also, the demuxer layer as it currently exists can't deal with dynamically removing external tracks either. Maybe some time in the future.) Instead, add a gross hack, that essentially reseeks the audio if it detects that it's too far off. The result is actually not too bad, because we can reuse the mechanism that is used for instant track switching. This way we can make sure of the right position, without having to care about certain other issues. It should be noted that if the audio demuxer is used for other tracks too, and the demuxer does not support refresh seeking, audio will probably be off by even a higher amount. But this should be rare.
| * player: fix mid-stream audio sync conditionwm42016-08-071-3/+3
| | | | | | | | | | | | | | | | | | | | This code is for resyncing audio-only streams (e.g. switching between audio tracks if no video track is active). This must not be run if the video PTS just isn't known yet. (Although the case in which this changes anything is probably very obscure, if it can even happen. Still, it's a bit more correct.) This is a correction to commit 91a3bda6.
| * player: fix display-sync timing if audio take long on resumewm42016-08-073-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In display-sync mode, the very first video frame is idiotically fully timed, even though audio has not been synced yet at this point, and the video frame is more like a "preview" frame. But since it's fully timed, an underflow is detected if audio takes longer than the display time of the frame (we send the second frame only after audio is done). The timing code will try to compensate for the determined desync, but it really shouldn't. So explicitly discard the timing info in this specific case. On the other hand, if the first frame still hasn't finished display, we can pretend everything is ok. This is a hack - ideally, we either would send a frame without timing info (and then send it again or so when playback starts properly), or we would add real pause support to the VO, and pause it during syncing.
| * demux_timeline: enable refresh seeks in some situationswm42016-08-071-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | Play a trick to make the packet pos field monotonically increasing over segment boundaries if the source demuxers return monotonically increasing pos values. This allows the demuxer to uniquely identify packets with the pos field, and can do refresh seeks using that. Normally, the packet pos field is used as a fallback for determining the playback position if the demuxer returns no proper duration. But demux_timeline.c always will, and the packet pos fields usually make no sense in relation to the returned file size anyway if the timeline source demuxers originate from separate streams.
| * demux: make refresh seek handling more genericwm42016-08-064-19/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove the explicit whitelisting of formats for refresh seeks. Instead, check whether the packet position is somewhat reliable during demuxing. If there are packets without position, or the packet position is not monotonically increasing, then do not use them for refresh seeks. This does not make sure of some requirements, such as deterministic seeks. If that happens, mpv will mess up a bit on stream switching. Also, add another method that uses DTS to identify packets, and prefer it to the packet position method. Even if there's a demuxer which randomizes packet positions, it hardly can do that with DTS. The DTS method is not always available either, though. Some formats do not have a DTS, and others are not always strictly monotonic (possibly due to libavformat codec parsing and timestamp determination issues).
| * player: sync audio as well when enabling it mid-streamwm42016-08-061-0/+3
| | | | | | | | | | | | If an audio track is enabled during playback, then make it resume at the exact "current position", instead of playing audio before that position. This was already done for video.
| * demux: fix a minor race conditionwm42016-08-061-10/+12
| | | | | | | | | | | | | | | | | | | | | | | | If the packet read function returns, and EOF was detected, and a seek was issued in the meantime, then don't use the EOF result. The seek will be processed later, and reset the EOF state anyway. The main effect is probably that we don't return EOF to the decoders (which the playback core resets before issuing the seek), and that we won't log an EOF message. Not important, but slightly more correct.
| * player: improve instant track switchingwm42016-08-065-87/+80
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When switching tracks, we normally have the problem that data gets lost due to readahead buffering. (Which in turn is because we're stubborn and instruct the demuxers to discard data on unselected streams.) The demuxer layer has a hack that re-reads discarded buffered data if a stream is enabled mid-stream, so track switching will seem instant. A somewhat similar problem is when all tracks of an external files were disabled - when enabling the first track, we have to seek to the target position. Handle these with the same mechanism. Pass the "current time" to the demuxer's stream switch function, and let the demuxer figure out what to do. The demuxer will issue a refresh seek (if possible) to update the new stream, or will issue a "normal" seek if there was no active stream yet. One case that changes is when a video/audio stream is enabled on an external file with only a subtitle stream active, and the demuxer does not support rrefresh seeks. This is a fuzzy case, because subtitles are sparse, and the demuxer might have skipped large amounts of data. We used to seek (and send the subtitle decoder some subtitle packets twice). This case is sort of obscure and insane, and the fix would be questionable, so we simply don't care. Should mostly fix #3392.
| * build: always require atomicswm42016-08-052-26/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Always require them, instead of just for some components which have hard requirements on correct atomic semantics. They should be widely available, and are supported by all recent gcc and clang compiler versions. We even have the fallbacks builtins, which should keep this working on very old gcc releases. In particular, w32_common.c recently added a hard requirement on atomics, but checking this properly in the build system would have been messy. This commit makes sure it always works. The fallback where weak atomic semantics are always fine is in theory rather questionable as well.
| * ao_wasapi: in exclusive mode do not output multichannel by defaultwm42016-08-051-1/+1
| | | | | | | | | | | | | | | | Exactly the same situation as with ao_alsa in commit 0b144eac (except that we can detect the situation better under wasapi). Essentially, wasapi will allow us to output any sample format, and not just the one configured by the user in the audio system settings.
| * w32_common: don't wait for GUI thread when polling for eventswm42016-08-051-8/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | VOCTRL_CHECK_EVENTS is called on every frame. This is by design, and is supposed to check the event queue of the windowing API. With the decoupled GUI thread in w32_common.c this doesn't make too much sense, and the purpose of VOCTRL_CHECK_EVENTS is really reduced to checking event flags. Even worse, waiting on the GUI thread can interfere with playback, since win32 sometimes blocks the event loop (e.g. clicking the window title bar). Change the code such that we really only query the event flags. Use atomics to avoid having to add a new mutex. (We assume we always have real atomics available. The build system doesn't check this properly, and it could fall back to dummy atomics, which are not atomic.) Should help with #3393. Doesn't help if the core happens to send a synchronous request, most commonly via VOCTRL_SET_CURSOR_VISIBILITY or VOCTRL_UPDATE_PLAYBACK_STATE.
| * ao_null: use channel list option type for channel-layouts suboptionwm42016-08-051-11/+5
| |