summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* 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
| | | | | | | | | | | | | | | | | 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
|
* options: fix channels options copy/free operationswm42016-08-051-0/+6
| | | | | For some fucked up reason the arguments can be NULL. Makes no sense to me, but ok.
* tvi_v4l2: fix style in the uninit functionBen Boeckel2016-08-051-4/+6
|
* tvi_v4l2: explicitly brace the codeBen Boeckel2016-08-051-1/+4
| | | | | It's fine either way, but this code is weirdly formatted. Make it more explicit.
*