summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* 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
|
* 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
| | | | | | | | | | | | |