summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* 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.
* github: discourage bug reportswm42016-08-051-0/+3
|
* audio: use --audio-channels=auto behavior, except on ALSAwm42016-08-0417-82/+234
| | | | | | | | | | | | | | | | | | | | | | | This commit adds an --audio-channel=auto-safe mode, and makes it the default. This mode behaves like "auto" with most AOs, except with ao_alsa. The intention is to allow multichannel output by default on sane APIs. ALSA is not sane as in it's so low level that it will e.g. configure any layout over HDMI, even if the connected A/V receiver does not support it. The HDMI fuckup is of course not ALSA's fault, but other audio APIs normally isolate applications from dealing with this and require the user to globally configure the correct output layout. This will help with other AOs too. ao_lavc (encoding) is changed to the new semantics as well, because it used to force stereo (perhaps because encoding mode is supposed to produce safe files for crap devices?). Exclusive mode output on Windows might need to be adjusted accordingly, as it grants the same kind of low level access as ALSA (requires more research). In addition to the things mentioned above, the --audio-channels option is extended to accept a set of channel layouts. This is supposed to be the correct way to configure mpv ALSA multichannel output. You need to put a list of channel layouts that your A/V receiver supports.
* player: remove special-case for DL/DR speakerswm42016-08-043-43/+0
| | | | | | Pointless anyway. With superficial checking I couldn't find any decoder which actually outputs this, and AO chmap negotiation would properly ignore them anyway in most cases.
* options: un-restrict --audio-delaywm42016-08-041-1/+1
| | | | Not a real reason to restrict its value range.
* player: offset demuxer on start/seek properly with audio/sub delaywm42016-08-044-0/+22
| | | | | | | | | | | | | | | | | Assume you use a large value like --audio-delay=20. Then until now the player would just have seeked normally to a "too late" position, and played silence for about 20 seconds until audio in the correct time range is coming again. Change this by offsetting seeks by the right amount. This works for both external and muxed files. If a seek isn't precise, then it works only for external files. This might cause issues with very large delay options. Hr-seek skipping could take a lot of time (especially because it affects video too), the demuxer queue could overflow, and other weird corner cases could appear. But we just try this on best-effort basis, and if the user uses extreme values we don't guarantee good behavior.
* vo_opengl_cb: log better error message if OpenGL not initialized by userwm42016-08-031-0/+6
| | | | | Otherwise opengl/video.c would confusingly complain about a wrong version, which in this case makes no sense.
* af_lavcac3enc: skip output if there was no input framewm42016-08-021-0/+3
| | | | Unrealistic corner case: drainning was initiated right after a seek.
* wayland_common: check for NULL current_output on fs switchingRostislav Pehlivanov2016-08-011-2/+3
| | | | | | | Prevents segfaults when a fullscreen switch is issued before fully initializing the VO. Doesn't change anything since the schedule_resize is only there to resize in case the image size switches, which happens long after init.
* af_lavcac3enc: fix buffering timestamps calculationswm42016-08-011-3/+9
| | | | In theory, an encoder could buffer some data.
* af_lavcac3enc: fix memory leakwm42016-08-011-1/+1
| | | | A major one. Oops.
* wayland_common: provide the real scaled window resolutionRostislav Pehlivanov2016-08-011-3/+5
| | | | | | It makes more sense to completely abstract this scaling inside the backend so that internally the player only works with real actual drawn pixels.
* af_lavcac3enc: fix a debug messagewm42016-07-311-1/+1
|
* af_lavcac3enc: error out properly if encoding failswm42016-07-311-0/+4
|
* af_lavcac3enc: fix aspects of AVFrame handlingwm42016-07-311-0/+3
| | | | | | | | | | We send a refcounted frame to the encoder, but then disrespect refcounting rules and write to the frame data without making sure the buffer is really writeable. In theory this can lead to reallocation on every frame is the encoder really keeps a reference. If we really cared, we could fix this by providing a buffer pool. But then again, we don't care.
* audio: make mp_audio_realloc[_min] ensure frame is writeablewm42016-07-311-1/+10
| | | | | | | | This is logical: the function makes sense only in situations where you are going to write to the audio data. To make it worse, av_buffer_realloc() also handles this situation, but only if the buffer size changes (simply because it can't realloc memory in use), so we have to explicitly force reallocation by unreffing the buffers first.
* ytdl: Error out with http_dash_segmentsRicardo Constantino2016-07-301-0/+4
| | | | Unsupported for now.
* options: add vp9 to --hwdec-codecswm42016-07-302-4/+4
|
* wayland_common: fix fullscreen image switching bugRostislav Pehlivanov2016-07-303-6/+4
| | | | | | | | | | | The problem was that when in fullscreen, switching between images did not issue a resize event, causing none of the images to be rendered correctly. This fixes the problem by issuing a resize event with the screen width and height. This commit also moves the zeroing of the events field to when it gets retrieved by mpv rather than randomly after a resize in the vo/backend code.
* wayland_common: prevent black bars on most non-native aspect ratiosRostislav Pehlivanov2016-07-301-0/+3
| | | | | | | | | ssurface_handle_configure()'s width and height are just hints given by the compositor, the application's free to not respect those strictly and to compensate for e.g. aspect ratio. This prevents crazy scenarios in which pictures with portrait aspect ratios have a huge black area to make them 16:9 or whatever the compositor feels like.
* demux_raw: s16be support was missing due to small typoEric Toombs2016-07-301-1/+1
| | | | Signed-off-by: wm4 <wm4@nowhere>
* wscript: add proper non-version'd SONAME for AndroidJan Ekström2016-07-301-1/+7
| | | | | This seems to have become a requirement since API target 23+, and matches what FFmpeg does.
* build: add --htmldir optionChris Mayo2016-07-302-1/+2
| | | | | Defaults to docdir but makes it possible to install html documentation separately.
* wayland_common: clip window size to the display output sizeRostislav Pehlivanov2016-07-301-5/+7
| | | | | | | | With X11 it was usually left up to the window manager to prevent huge windows from being out of range, but no Wayland compositor will do this right now. Hugely improves usability when using mpv as an image viewer.
* wayland_common: flush wakeup_pipe on a wakeupRostislav Pehlivanov2016-07-301-8/+10
| | | | | | Missed during the recent changes. Also simplify error checking code and check for POLLNVAL as well (the display fd was never actually checked to be valid).
* osdep/io: introduce mp_flush_wakeup_pipe()Rostislav Pehlivanov2016-07-305-10/+14
| | | | Makes a fairly common occurence with wakeup_pipes easier to handle.
* wayland_common: remove untested/unusable wayland dnd codeRostislav Pehlivanov2016-07-302-188/+1
| | | | | Not worth keeping 200 lines of untestable as of today code which might be broken, if it hasn't been already.
* vo_opengl: remove the 3dlut-size npot2 restrictionNiklas Haas2016-07-253-3/+4
| | | | | | | | This requires changing the pixel upload alignment because the odd sizes might not be aligned to multiples of 4. Anyway, the restriction has no real benefit and the sizes in between 32 and 64 might be worth using, so just drop it.
* vo_opengl: reduce default 3dlut-size to 64x64x64Niklas Haas2016-07-252-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | Following testing after ebe798a, this is a more than sufficient size to cover our use case. The old default was a drop of about 58 dB PSNR using the old code, and this new default is about 65 dB PSNR, so it's actually an improvement despite resulting in a smaller size. There was no outlier whatsoever when comparing sizes around the 64 neighbourhood (with every step corresponding to a PSNR drop of about 0.07 dB), so I picked this since it's a power of two and requires no change to the current 3dlut-size parsing logic. I also tested smaller sizes such as 32x32x32 which performed almost as well on colorful samples, but this results in noticeable black boost in the dark regions, which is pretty undesirable. Therefore, we should avoid going much further below 64x64x64. Either way, this new size is so fast to compute that the 3dlut cache is almost useless on my end. In fact, it might even be slower to load the profile from the cache than to recompute it from scratch. (For caches on a disk. For cache on a tmpfs, it makes no difference)
* x11: do not accidentally discard event flagswm42016-07-252-6/+5
| | | | | | | | | It seems vo_x11_check_events() was supposed to return the currently flagged events and reset them. But there are many places where vo_x11_check_events() is called without checking its return value. This could lead to forgotten events. Change the code such that they can't get lost.
* vo_opengl: increase 3DLUT accuracy at lower LUT sizesNiklas Haas2016-07-251-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | This code had the exact same texture indexing bug that the original scaler code had before the introduction of the LUT_POS macro to fix it. We can re-use this same macro here, and the performance drop is virtually entirely negligible. The benefit is greatly improved LUT accuracy as the 3DLUT size decreases - in particular, the old LUT started introducing more and more black crush the lower your LUT size is (because the error was essentially an over-contrast bias, with a magnitude linearly related to the lut size). The new code improves black stability as the LUT size decreases, and only at very low values (16 and below) do black levels start noticeably getting affected (due to crude linearization of the nonlinear response curve). The default value of 3dlut-size is definitely generous enough for this to make no difference out of the box, but it also causes no performance drop at all on my machine so I see no harm in improving the logic. Furthermore, this means we could easily decrease the default 3dlut size in a future commit, perhaps even down to 64x64x64 as a default. (But more testing is warranted here)
* audio: use idiotic FFmpeg ABI rules for public-except-not-public fieldswm42016-07-241-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The FFmpeg API is incredibly weird and inconsistent about this. This is also a FFmpeg-only issue and nothing like this is in Libav - which doesn't really show FFmpeg in a very positive light. (To make it even worse: this is a full-blown Libav API incompatibility, even though this crap was added for Libav ABI-compatibility. It's absurd.) Quoting the FFmpeg header for the AVFrame.channels field: /** * number of audio channels, only used for audio. * Code outside libavutil should access this field using: * av_frame_get_channels(frame) * - encoding: unused * - decoding: Read by user. */ int channels; It says "should" not must, and it doesn't even mention av_frame_set_channels(). It's also in the section for public fields (not below a marker that indicates private fields in a public struct, like it's done e.g. in AVCodecContext). But not using the accessor will cause silent failures on ABI changes. The failure that happened due to this code didn't even make it apparent what was wrong. So just use the idiotic accessor. Also harmonize the FFmpeg-cursing in the code. (It's fully justified.) Fixes #3295. Note that mpv will still check the exact library version numbers, and reject mismatches - to protect itself from such issues in the future.
* player: disable DS with spdif transcoding toowm42016-07-241-2/+5
| | | | | | Otherwise it behaves dumb. (Although you could argue it shouldn't try to guess whether speed changes work, but instead simply disable DS if they don't work.)
* af_lavcac3enc: use common code for AVFrame setupwm42016-07-243-16/+22
|
* demux_lavf: remove subtitle seeking special-casewm42016-07-241-22/+7
| | | | | | | | It used not to work - but now it apparently does. Not sure when that got fixed in FFmpeg, but there's no longer a reason to keep this hack. This also gets rid of the check for the read_seek2 field, which is not part of the public API.
* vo_opengl: glctx can be NULL during initwm42016-07-211-1/+1
| | | | | | | This fixes a crash that can happen with the Cocoa backend: it calls vo_wakeup() during init, which calls vo_opengl.c/wakeup(). Fixes #3360.
* x11, wayland: do not accidentally close FD 0wm42016-07-212-2/+6
| | | | | | | | | | Both backends have code to close each FD of their wakeup_pipe array. This array is default-initialized with 0, which means if the backends exit before the wakeup pipe is created (e.g. when probing), they would close FD 0. Initialize the FDs with -1. Then we call close(-1) in these situations, which is perfectly allowed and has no bad consequences.
* vo: remove now unused event_fd handlingwm42016-07-212-62/+8
|
* wayland_common: make function declaration consistentRostislav Pehlivanov2016-07-211-23/+21
| | | | Half the code had a space before the arguments and half didn't.
* wayland: port to the new wakeup/wait_events frameworkRostislav Pehlivanov2016-07-214-71/+53
| | | | | | | | | | | | This fits natively into the vo/backend and allows to simplify the polling code. One new change is the fact that surface_handle_enter flags VO_EVENT_WIN_STATE and VO_EVENT_RESIZE instead of only VO_EVENT_WIN_STATE. Before this, the code hackily relied on the timeout and the loop in the wait_frame function to track and set the scaling factor. Instead, this triggers mpv to run a schedule_resize and adjust the new VO output dimensions immediately. This is also more accurate since surface_handle_enter() gets called when a surface is created, moved and resized, which is exactly what the rest of the player might be interested in.
* manpage: not-document tscale=linearwm42016-07-211-0/+3
|
* vo_opengl: add a tscale=linear direct implementationNiklas Haas2016-07-211-3/+10
| | | | | | | | | | This uses GLSL mix() instead of going through an indirect texture access. Easy to implement and might require less resources on some devices, since the oversample code was already essentially just a special case of this. Could be made the new default (as per issue #2685), but that should be done in a separate commit.
* cocoa: remove unused icc profile variablesAkemi2016-07-211-2/+0
|
* cocoa: update screen fps only if necessaryAkemi2016-07-211-1/+3
| | | | | we don't need to update the display refresh rate when going fullscreen or updating the colour profile
* x11: stop using vo.event_fdwm42016-07-208-1/+72
| | | | Instead let it do its own event loop wakeup handling.
* vo_opengl: allow backends to provide callbacks for custom event loopswm42016-07-206-17/+51
| | | | | | | Until now, this has been either handled over vo.event_fd (which should go away), or by putting event handling on a separate thread. The backends which do the latter do it for a reason and won't need this, but X11 and Wayland will, in order to get rid of event_fd.
* vo_wayland: fix high CPU usage due to busy pollingRostislav Pehlivanov2016-07-191-3/+3
| | | | | | There's no need to call wl_display_flush() since all the client-side buffered data has already been flushed prior to polling the fd. Instead only check for POLLIN and the usual ERR+HUP.
* x11: skip ICC update on every window movewm42016-07-182-11/+26
| | | | | | | Don't just cause vo_opengl to update the ICC profile every time the window is moved. Instead, explicitly check if the screen was changed. Mostly untested.
* libarchive: sanitiz