summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* Release 0.20.0v0.20.0Martin Herkt2016-08-263-1/+45
|
* Merge branch 'master' into release/currentMartin Herkt2016-08-2645-256/+583
|\
| * demux: close underlying stream if it's fully read anywaywm42016-08-263-3/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is for text subtitles. libavformat currently always reads text subtitles completely on init. This means the underlying stream is useless and will consume resources for various reasons (network connection, file handles, cache memory). Take care of this by closing the underlying stream if we think the demuxer has read everything. Since libavformat doesn't export whether it did (or whether it may access the stream again in the future), we rely on a whitelist. Also, instead of setting the stream to NULL or so, set it to an empty dummy stream. This way we don't have to litter the code with NULL checks. demux_lavf.c needs extra changes, because it tries to do clever things for the sake of subtitle charset conversion. The main reason we keep the demuxer etc. open is because we fell for libavformat being so generic, and we tried to remove corresponding special-cases in the higher-level player code. Some of this is forced due to ass/srt mkv/mp4 demuxing being very similar to external text files. In the future it might be better to do this in a more straight-forward way, such as reading text subtitles into libass and then discarding the demuxer entirely, but for aforementioned reasons this could be more of a mess than the solution introduced by this commit. Probably fixes #3456.
| * player: don't directly access demuxer->streamwm42016-08-264-6/+7
| | | | | | | | | | | | | | | | | | | | Cleaner and makes it easier to change the underlying stream. mp_property_stream_capture() still directly accesses it directly via demux_run_on_thread(). This is evil, but still somewhat sane and is not getting into the way here. Not sure if I got all field accesses.
| * cache: don't use a backbuffer if the cache is as large as the filewm42016-08-261-10/+14
| | | | | | | | | | | | | | | | | | | | | | | | It's just wasted memory. One corner case is when a file grows during playback, but this is rare and usually happens on-disk only. The cache size was generally limited before this change already, so no reason to care. As an unrelated change, move the cache size info to the resize_cache() function. There's really no reason not to do this, and it's slightly more informative if the user changes the cache size at runtime.
| * stream_memory: disable stream cachewm42016-08-261-0/+1
| | | | | | | | Obviously makes no sense and just wastes resources.
| * w32_common: use hooks to detect parent window resizeJames Ross-Gowan2016-08-261-35/+117
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Because VOCTRL_CHECK_EVENTS is processed asynchronously (as of 088a007,) the GUI thread no longer gets regular wakeups, so the old check that made sure the video window matched the parent window's size in --wid embedding mode did not run very often. This made --wid embedding not very usable. Instead of polling for window size changes, use Windows hooks to react to them when they happen. When the parent window is owned by the same process as the video window, use a WH_CALLWNDPROC hook. When the parent window is not owned by the same process, WinEvents must be used, which are not as smooth, but still work for this purpose. Since neither SetWindowsHookEx nor SetWinEventHook take a context parameter to send data to the hook function, the hook functions must find the child window by its class instead, so there are a few changes to ensure this is fast and the class is unique. This also fixes up the logic to handle window destruction. When a parent window is destroyed, its children are also destroyed, so this gives us a way to react to parent window destruction without polling.
| * vo_opengl: angle: new opengl flag to control DirectCompositionAvi Halachmi (:avih)2016-08-254-2/+23
| | | | | | | | | | On some systems DirectComposition might behave poorly. Add an opengl suboption flag 'dcomposition' (default=yes) which can disable it.
| * x11: work around mutter fullscreen issuewm42016-08-251-3/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the video has the same size as the screen, starting with --fs and then leaving fullscreen doesn't actually leave fullscreen. The reason is that mpv tries to restore the previous window size if necessary (otherwise, you'd end up with a Window of nearly the same size as the screen with some WMs). It will typically restore with the rectangle set exactly to the screen if no other position or size is forced. This triggers pre-EWMH fullscreen mode, which WMs detect using various heuristics. Apparently we triggered this with mutter (but strangely no other WMs). It's possible that pre-EWMH fullscreen mode actually requires removing decorations, and mutter either ignores this. But this is speculation and I haven't checked. Work this around by reducing the requested size by 1 pixel if it happens. This was observed with mutter 3.18.2. Fixes #2072.
| * audio: avoid missed wakeups with ab-loopswm42016-08-241-1/+5
| | | | | | | | Could get "stuck".
| * vd_lavc: minor simplificationwm42016-08-231-3/+1
| | | | | | | | The timebase is now always valid.
| * ad_lavc: actually tell decoder about the timebasewm42016-08-231-0/+1
| | | | | | | | Essentially forgotten in commit 05e4df3f.
| * ao_alsa: log if retrieving supported channel maps failswm42016-08-221-1/+3
| | | | | | | | It's a sign that the driver doesn't implement the channel map API.
| * audio: do not apply --audio-channels if spdif passthrough is in usewm42016-08-221-5/+9
| | | | | | | | | | | | | | | | If spdif is enabled, the channel layout has no meaning other than setting the number of channels. The number of channels must be fixed to achieve the exact bitrate required. Fixes #3445.
| * demux: demote packet queue overflow to a warningwm42016-08-221-3/+3
| | | | | | | | | | | | | | | | | | It doesn't necessarily have to mean anything bad. We're still too lazy to provide any more detailed information (e.g. whether this happened to likely bad interleaving, excessive amount of packets like with some ASS subs, or that the readahead user option is limitted by the packet queue size).
| * player: log if video is considered an imagewm42016-08-211-0/+1
| | | | | | | | It's a heristic that can fail, so better log it.
| * manpage: fix typowm42016-08-201-1/+1
| |
| * vo: be more trusting to estimated display FPSwm42016-08-201-8/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This should actually be rather safe - we already check whether the estimated value jitters less than the (possibly untrustworthy) nominal one. Remove a "safety" check that disabled this code for small deviations, and make it trigger sooner into playback. Also lower the log level of messages about using the estimated display FPS down to verbose. Normally there's another mechanism for smoothing out minor estimation differences, but that is not good enough here. This possibly improves behavior as reported in #3433, which can be reproduced with --vo=null:fps=48.426 --display-fps=48 (though it doesn't consider the jitter introduced by a real VO).
| * player: update Windows playback state asynchronouslywm42016-08-203-8/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Doing this required synchronizing with the VO thread, which could lead to audio dropouts if the VO was frozen (which can happen in practice if e.g. an opengl_cb user is not doing what the API demands). Add a way to send asynchronous VOCTRLs, and use that for the playback state. In theory, it would be better to make this status update a several function and to "merge" several queued update, but that would be slightly more effort/code, and the update is so infrequent that the merging would never happen anyway. The change to vo_destroy() is to make sure all queued asynchronous reuqests are finished before making the vo_thread exit. Even though it's only used on MS Windows, it's run on any platform with any VO, which makes this worse.
| * ta: add a helper macrowm42016-08-201-0/+4
| |
| * vo: fix mismatching types in pointer operationwm42016-08-202-3/+3
| | | | | | | | | | | | | | run_control() dereferences an uint32_t as int. Whether this is allowed depends on what uint32_t is typedefed to (dereferencing an unsigned int as int should be fine). Fix it by always using int. The uint32_t type never really made sense.
| * af_lavrresample: better swr reinitializationPaul B Mahol2016-08-201-4/+5
| |
| * manpage: info about --panscan vs. --video-unscaledrr-2016-08-191-1/+4
| |
| * aspect: add --video-unscaled=downscale-bigrr-2016-08-193-7/+13
| |
| * af_lavrresample: fix error if resampler could not be recreatedwm42016-08-191-4/+5
| | | | | | | | | | | | | | | | There are situations where the resampler is destroyed and recreated during playback. If recreating the resampler unexpectedly fails, the filter function is supposed to return an error. This wasn't done correctly, because get_out_samples() accessed the resampler before the check. Move the check up to fix this.
| * command: prevent O(n^2) behaviour for playlist propertyJames Ross-Gowan2016-08-201-3/+25
| | | | | | | | | | | | | | | | | | When fetching the playlist property, playlist_entry_from_index would be called for each playlist entry, which traversed a linked list to get the entry corresponding to the specified index. This was very slow for large playlists. Since get_playlist_entry is called for each index in order, it can avoid a full traversal of the linked list by using the next pointer on the previously requested entry.
| * vd_lavc: remove unnecessary initializationwm42016-08-191-1/+0
| | | | | | | | This is already the default value.
| * demux: change fps field to doublewm42016-08-191-1/+1
| | | | | | | | Because why not.
| * video/audio: always provide "proper" timestamps to libavcodecwm42016-08-198-5/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of passing through double float timestamps opaquely, pass real timestamps. Do so by always setting a valid timebase on the AVCodecContext for audio and video decoding. Specifically try not to round timestamps to a too coarse timebase, which could round off small adjustments to timestamps (such as for start time rebasing or demux_timeline). If the timebase is considered too coarse, make it finer. This gets rid of the need to do this specifically for some hardware decoding wrapper. The old method of passing through double timestamps was also a bit questionable. While libavcodec is not supposed to interpret timestamps at all if no timebase is provided, it was needlessly tricky. Also, it actually does compare them with AV_NOPTS_VALUE. This change will probably also reduce confusion in the future.
| * av_common: improve rounding for float->int timestamp conversionswm42016-08-191-2/+4
| |
| * player: refresh very low framerate video on filter changeswm42016-08-191-1/+3
| | | | | | | | | | | | | | Limit the max. time the refresh is delayed. Make it refresh at all if image mode is enabled. Fixes #3435.
| * vf_rotate: allow arbitrary rotationwm42016-08-192-4/+11
| | | | | | | | | | | | | | vf_rotate selects the correct filter for 90° rotation, but it can be extended to use lavfi's vf_rotate as fallback. See #3434.
| * github: fix typowm42016-08-181-1/+1
| |
| * github: encourage bug reportswm42016-08-181-1/+3
| | | | | | | | | | Word this sentence slightly more positively because we are a positive project.
| * demux_lavf: don't report start time for oggwm42016-08-181-2/+6
| | | | | | | | | | Better with ogg shoutcast streams. These have PTS resets on each playlist item, so the PTS would usually reset to some negative value.
| * player: make looping slightly more seamlesswm42016-08-185-42/+38
| | | | | | | | | | | | This affects A-B loops and --loop-file, and audio. Instead of dropping audio by resetting the AO, try to make it seamless by not sending data after the loop point, and after the seek send new data without a reset.
| * audio: improve aspects of EOF handlingwm42016-08-183-19/+47
| | | | | | | | | | | | | | | | | | | | | | The code actually kept going out of EOF mode into resync mode back into EOF mode when the playloop had to wait after an audio EOF caused by the endpts. This would break seamless looping (as added by the next commit). Apply endpts earlier, to ensure the filter_audio() function always returns AD_EOF in this case. The idiotic ao_buffer makes this an amazing pain in the ass.
| * video: don't discard video frames after endptswm42016-08-183-3/+13
| | | | | | | | | | | | | | | | | | | | | | | | Instead of letting it keep decoding by trying to find a new frame, "plug" the frame queue by not removing it. (Or actually, by putting it back instead of discarding it.) Matters for seamless looping (following commits), and possibly some other corner cases. The added function vf_unread_output_frame() is a bit of a sin, but still reasonable, since its implementation is trivial.
| * build: make avutil-mastering-metadata check slightly more robustwm42016-08-181-1/+1
| | | | | | | | | | Fixes the specific scenario of compiling against a local Libav build, while the system has FFmpeg installed.
| * manpage: input: fix define-section syntaxjaseg2016-08-171-2/+2
| | | | | | | | Source says "force", manpage said "forced". Now both say "force".
| * player: add option to control duration of image displaywm42016-08-175-12/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | The --image-display-duration option controls how long an image is displayed. It's also possible to display the image forever (until manual user interaction stops playback). With this, the core drops the old method to "drain" video (i.e. waiting for the last frame duration on end of playback). Instead, we reuse MPContext.time_frame. The old mechanism was disabled for non-images anyway. Fixes #3425.
| * m_option: add mechanism to allow inf/-inf float optionswm42016-08-171-1/+2
| | | | | | | | Used by the next commit.
| * m_option: simplify float value range handlingwm42016-08-171-21/+3
| | | | | | | | | | | | Use clamp_double() to handle all value restriction/verification. The error messages become a bit less nice, but they were kind of incomplete before.
| * demux: fix undefined behavior with ogg metadata updatewm42016-08-161-1/+1
| | | | | | | | | | | | | | | | | | | | When an ogg track upodates metadata, we have to perform a complicated runtime update due to the demux.c architecture. A detail was broken and an array was allocated with the previous number of streams, which usually led to invalid memory write accesses at least on the first update. See github commit comment on commit b9ba9a89.
| * af_lavrresample: work around libswresample misbehaviorwm42016-08-161-10/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The touched code is for seek resets and such - we simply want to reset the entire resample state. But I noticed after a seek a tiny bit of audio is missing (mpv's audio sync code inserted silence to compensate). It turns out swr_drop_output() either does not reset some internal state as we expect, or it's designed to drop not only buffered samples, but also future samples. On the other hand, libavresample's avresample_read(), does not have this problem. (It is also pretty explicit in what it does - return/skip buffered data, nothing else.) Is the libswresample behavior a bug? Or a feature? Does nobody even know? Who cares - use the hammer to unfuck the situation. Destroy and deallocate the libswresample context and recreate it. On every seek.
| * player: allow passing flags to queue_seek()wm42016-08-156-24/+31
| | | | | | | | | | | | | | | | | | | | | | | | Change the last parameter from a bool to an int, which is supposed to take bit-flags. The at this point only flag is MPSEEK_FLAG_DELAY, which replaces the previous bool parameter. The old false parameter becomes 0, the old true parameter becomes MPSEEK_FLAG_DELAY. Since the old "immediate" parameter is now essentially inverted, two coalesced immediate and delayed seeks end up as delayed instead of immediate. This change doesn't matter, since there are no relative immediate seeks anyway.
| * DOCS: Update versionMartin Herkt2016-08-152-2/+2
| |
* | 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
| | | | | | | | | |