summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* player: add pause state to playback start messagewm42020-09-211-2/+3
| | | | | Now the player tells you that audio or video are playing while paused, or something.
* terminal: fix segfault when backgroundingwm42020-09-211-2/+4
| | | | | | | | | In the recent terminal commit, I "compressed" the read() error handling, and messed it up. The return value could be -1 for other non-fatal errors (such as EIO when trying to read while backgrounded), which resulted in buf.len getting messed up. Fixes: 602384348e718c77
* f_decoder_wrapper: make log prefix less verbosewm42020-09-201-2/+2
|
* audio: take paused state into account in ao_start()sfan52020-09-201-1/+1
| | | | | It makes no sense to instruct the AO to start the pull callbacks when we know there's nothing to play (only affects pull AOs).
* audio: move start() calls outside of locksfan52020-09-201-3/+10
| | | | | Pull based AOs might want to call ao_read_data() inside start(). This fixes ao_opensles deadlocking.
* mac: add an option to change the App activation policyder richter2020-09-204-1/+28
| | | | useful to hide the app icon in the Dock if necessary.
* mac: add ontop window level for desktopder richter2020-09-203-4/+9
| | | | | | this puts the window ontop of the desktop but behind the desktop icons. Fixes #7791
* options: simplify --android-surface-size handlingsfan52020-09-205-27/+8
|
* build: disable GLXwm42020-09-181-2/+3
| | | | | | Nobody needs this anymore. If not too many people complain, we'll remove this completely. Many already consider X11 and OpenGL legacy, so we don't need TWO X11/OpenGL backends.
* manpage: fix console keybindings punctuationGuido Cella2020-09-181-3/+3
|
* msg: make --msg-time show time in secondswm42020-09-182-2/+2
| | | | | More readable, similar to what --log-file will use (although the terminal code shows microseconds and uses less left padding).
* build: sort dependencies (to make build deterministic)Philip Sequeira2020-09-181-1/+1
| | | | Fixes #7855.
* command, demux: make drop-buffers reset state even harderwm42020-09-172-4/+10
| | | | Leave nothing left when it's executed.
* terminal: attempt to handle the ESC keywm42020-09-171-24/+22
| | | | | | | | | | | | | | | | | | Due to Unix being legacy garbage, it's not possible to safely detect the ESC key on terminal. The key sequences are ambiguous. The code for the ESC key also starts the sequences for other special keys. Until now, you needed to hit ESC twice for it to be recognized. Attempt to handle this better by using a timeout to detect the key. If ESC is in the input buffer, but nothing else arrived after a timeout, assume it's the ESC key. I think this is the method vim uses. Currently, the timeout is set at 100ms. This is hardcoded and cannot be changed. It's possible that this causes problems on slow ssh connections or so. I'm not sure what exactly happens if you manage to get ESC + another normal key into the input buffer. If it's a known sequence, it will be matched and interpreted as such. If not, it'll probably be discarded.
* client API: update alignment requirements for software renderingwm42020-09-171-9/+12
| | | | | | | Previous commit fixes it for libswscale. The libzimg path has extra code to copy by slice, but it still may access pixel groups using normal memory accesses (for example, reading rgba pixel data via uint32_t), so document a minimum alignment requirement per pixel format.
* sws_utils: work around libswscale corrupting memory yet againwm42020-09-172-2/+57
| | | | | | | | | | | | | | | | | | | | If the alignment is less than 16, certain libswscale code paths will silently corrupt memory outside of the target buffer. This actually affected the libmpv software rendering API (that was fun to debug). Rather than passing this problem to the next API user, try to avoid it within libmpv. It's unclear which alignment libswscale requires for safe operation. I'm picking 32 (one more than the observed safe value in the case I experienced), because libavfilter mostly uses this value. The way to work this around is slow: just make a full copy of the entire input or output image. Possibly this could be optimized by using the slice API, but that would be more effort, and would likely expose further libswscale bugs. Hope that this is a rarely needed path. The next commit will update the alignment requirement documentation bits.
* manpage: refer to --sub-color for colorsGuido Cella2020-09-171-4/+4
| | | | | Don't make the user search for --osd-color only to make him search again for --sub-color.
* manpage: mark file-local-options as writableGuido Cella2020-09-171-1/+1
|
* stream_slice: interpret `end` as offset if it starts with '+'Mohammad AlSaleh2020-09-172-0/+11
| | | | | | | | Example: slice://1g-2g@file.ts (1 to 2) slice://1g-+2g@file.ts (1 to 3) Signed-off-by: Mohammad AlSaleh <CE.Mohammad.AlSaleh@gmail.com>
* command: add property track-list/N/main-selectionwnoun2020-09-122-0/+18
|
* player: fix inconsistent AO pause state in certain situationswm42020-09-122-8/+3
| | | | | | | | | | | | | | | | | | Pause can be changed during a file change, such as with for example --reset-on-next-file=pause, or in hooks, or by being quick, and in this case the AO's pause state was not updated correctly. mpctx->ao_chain is only set if playback is fully initialized, while the AO itself in mpctx->ao can be reused across files. Fix this by always running set_pause_state() if the pause option is changed. Could cause new bugs since running this used to be explicitly avoided outside of the loaded state. The handling of time_frame is potentially worrisome. Regression due to recent audio refactor; before that, the AO didn't have a separate/persistent pause state. Fixes: #8079
* player: some minor code golfwm42020-09-101-11/+6
|
* vo_vdpau: remove an unused variablewm42020-09-101-2/+0
|
* player: clamp relative seek base time to nominal durationwm42020-09-101-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since b74c09efbf7, audio-only files let you seek to arbitrary points beyond the end of the file (but still displayed the time clamped to the nominal file duration). This was confusing and just not wanted. The reason is probably that the commit removed setting the audio PTS for data before the seek target, so if you seek past the end of the file, the audio PTS is never set. This in turn means the logic to determine the current playback time has no PTS at all, and thus falls back to the seek PTS. This happened in the past for other reasons (like efe43d768f). I have enough of this, so I'm just changing the code to clamp the seek timestamp to a "known" range. Do this when seeking ends, because in the fallback case, the playback time shouldn't be stuck at e.g. "end + seek_argument". Also do it when initiating a new seek (mp_seek), because if the previous seek hasn't finished yet, it shouldn't add them up and allow it to go "out of range" either. The latter is especially relevant for hr-seeks. Doing this clamping is problematic because the duration is a possibly invalid value from the demuxer, or just missing. Especially with timestamp resets, fun sometimes happens, and in these situations it might be better not to clamp. One could argue you should just use the last audio timestamp returned by the decoder or demuxer (even if that directly conflicts with --end), but that sounds even more hairy. In summary: what a dumb waste of time, what the fuck.
* manpage: "fix" some formattingwm42020-09-101-4/+8
| | | | Yeah, fuck this retarded garbage.
* terminal-unix: attempt to support more CTRLwm42020-09-101-6/+14
| | | | | | | Hysterically stupid inconsistent legacy garbage from the 70ies or maybe even 60ies. What the fuck. I fucking hate computers so much. Fixes: #8072
* vo_vdpau: remove deprecated/inactive --vo-vdpau-deint optionwm42020-09-094-30/+1
| | | | | I think this has been dead code for quite a while. It was deprecated anyway.
* command: add read-only focused propertyGuido Cella2020-09-088-1/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a property that returns whether the window is focused, currently only for X11 and Wayland. My use cause for this is having an equivalent of pause-when-minimize.lua for tiling window managers: make mpv play only while it's in the current workspace or is focused (I'm fine with either one but prefer focus). On X I do this by observing display-names, which is empty when the rectangles of the display and mpv don't intersect, but on Wayland its value doesn't change when mpv leaves the current workspace (and the same check doesn't work since the geometries still intersect). This could later be made writable as requested in #6252. Note that on Wayland se shouldn't consider an unactivated window with keyboard input focused. The wlroots compositors I tested set activated after changing the keyboard focus, so if you set wl->focused only in keyboard_handle_enter() and keyboard_handle_leave() to avoid adding the "has_keyboard_input" member, focused isn't set to true when first opening mpv until you focus another window and focus mpv again. Conversely, if that order can't be assumed for all compositors, we should toggle wl->focused when necessary in keyboard_handle_enter() and keyboard_handle_leave() as well as in handle_toplevel_config().
* manpage: fix typoGuido Cella2020-09-061-4/+4
| | | | | Change 'already by defined' to 'already defined' and reformat the paragaph.
* options: fix a flags fieldwm42020-09-041-2/+2
|
* ao_alsa: make partial writes an error messagewm42020-09-031-2/+2
| | | | And I think "partial write" is easier to understand than "short write".
* audio: fix stream-silence with push AOs (somewhat)wm42020-09-032-5/+15
| | | | | | | | | | | | | | | | | | | | | | | | --audio-stream-silence is a shitty feature compensating for awful consumer garbage, that mutes PCM at first to check whether it's compressed audio, using formats advocated and owned by malicious patent troll companies (who spend more money on their lawyers than paying any technicians), wrapped in a wasteful way to make it constant bitrate using a standard whose text is not freely available, and only rude users want it. This feature has been carelessly broken, because it's complicated and stupid. What would Jesus do? If not getting an aneurysm, or pushing over tables with expensive A/V receivers on top of them, he'd probably fix the feature. So let's take inspiration from Jesus Christ himself, and do something as dumb as wasting some of our limited lifetime on this incredibly stupid fucking shit. This is tricky, because state changes like end-of-audio are supposed to be driven by the AO driver, while playing silence precludes this. But it seems code paths for "untimed" AOs can be reused. But there are still problems. For example, underruns will just happen normally (and stop audio streaming), because we don't have a separate heuristic to check whether the buffer is "low enough" (as a consequence of a network stall, but before the audio output itself underruns).
* encode: propagate errors to exit status properlywm42020-09-032-1/+7
| | | | | Don't just let mpv CLI return 0 (success) as exit status if encoding failed somehow.
* ao_lavc: slightly simplify filter usewm42020-09-031-12/+12
| | | | | | Create a central function which pumps data through the filter. This also might fix bogus use of the filter API on flushing. (The filter is just used for convenience, but I guess the overall result is still simpler.)
* client API: inactivate the opengl_cb APIwm42020-09-032-88/+13
| | | | | | | | | | The render API replaced the opengl_cb API over 2 years ago. Since then, the opengl_cb API was emulated on top of the render API. While it would probably be reasonable to emulate these APIs until they're removed in an eventual libmpv 2.0 bump, I have some non-technical reasons to disable the API now. The API stubs remain; they're needed for formal ABI compatibility.
* encode: disable unsupported media types automaticallywm42020-09-033-19/+57
| | | | | | | If you encode to e.g. an audio-only format, then video is disabled automatically. This also takes care of the very cryptic error message. It says "[vo/lavc] codec for video not found". Sort of true, but obscures the real problem if it's e.g. an audio-only format.
* encode: remove early EOF failure handlingwm42020-09-034-29/+0
| | | | | | | I don't see the point of this. Not doing it may defer an error to later. That's OK? For now, it seems better to reduce the encoding internal API. If someone can demonstrate that this is needed, I might reimplement it in a different way.
* audio: slightly simplify audio_start_ao()wm42020-09-031-10/+4
| | | | Get rid of an indirection; no behavior change.
* audio: reduce excessive logging of delayed audio startwm42020-09-032-2/+9
| | | | | | | Since this is a messy and fragile mechanism, I want it logged (even if it's somewhat in conflict with the verbose logging policy). On the other hand, it's unconditionally logged on every playloop iteration. So add some nonsense to log it only on progress.
* ao_alsa: log more information on short writeswm42020-09-021-2/+4
|
* audio: do not show audio draining message when it does not make sensewm42020-09-011-1/+3
| | | | | | Just for the redundant message. The function which is called here, ao_drain(), does not care in which state it is called, and already handled this gracefully.
* audio: do not wake up player when waiting for audio state and pausedwm42020-09-011-1/+2
| | | | Bullshit.
* audio: fix AVFrame allocation (crash with opus encoding)wm42020-09-011-0/+2
| | | | | | | | | | | | AVFrame doesn't have public code for pool allocation, so mpv does it manually. AVFrame allocation is very tricky, so we added a bug. This crashed with libopus encoding, but not some other audio codecs, because the libopus libavcodec wrapper accesses AVFrame.data. Most code tries to avoid accessing AVFrame.data and uses AVFrame.extended_data, because using the former would subtly corrupt memory on more than 8 channels. The fact that this problem manifested only now shows that most AVFrame consuming FFmpeg code indeed uses extended_data for audio.
* DOCS/interface-changes: remove encoding mode deprecation entrywm42020-09-011-1/+0
| | | | It was undeprecated.
* player/playloop.c: reorder included headers per contribute.mdLeo Izen2020-08-311-17/+14
| | | | | This commit sorts the included headers alphabetically and puts them in sections, as described by DOCS/contribute.md.
* ao_openal: restore working condition with new push APILAGonauta2020-08-311-8/+10
|
* ao: remove unused fieldwm42020-08-311-1/+0
|
* audio: fix inefficient behavior with ao_alsa, remove period_size fieldwm42020-08-297-24/+13
| | | | | | | | | | | | | | | | | | | | It is now the AO's responsibility to handle period size alignment. The ao->period_size alignment field is unused as of the recent audio refactor commit. Remove it. It turns out that ao_alsa shows extremely inefficient behavior as a consequence of the removal of period size aligned writes in the mentioned refactor commit. This is because it could get into a state where it repeatedly wrote single samples (as small as 1 sample), and starved the rest of the player as a consequence. Too bad. Explicitly align the size in ao_alsa. Other AOs, which need this, should do the same. One reason why it broke so badly with ao_alsa was that it retried the write() even if all reported space could be written. So stop doing that too. Retry the write only if we somehow wrote less. I'm not sure about ao_pulse.
* encode: undeprecatewm42020-08-291-2/+1
| | | | I guess the audio timestamp corruption problem is probably solved now.
* ring: remove thiswm42020-08-293-240/+0
| | | | | The code is OK, and it could be restored if it's needed again. But it is unused now, so remove it.
* audio_buffer: remove thiswm42020-08-293-200/+0
| | | | | | Unused, was terrible garbage. It was (or at least its implementation was) always a make-shift solution, and just gross bullshit. It is unused now, so delete it.
* audio: refactor how data is passed to AOwm42020-08-2912-768/+638
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This replaces the two buffers (ao_chain.ao_buffer in the core, and buffer_state.buffers in the AO) with a single queue. Instead of having a byte based buffer, the queue is simply a list of audio frames, as output by the decoder. This should make dataflow simpler and reduce copying. It also attempts to simplify fill_audio_out_buffers(), the function I always hated most, because it's full of subtle and buggy logic. Unfortunately, I got assaulted by corner cases, dumb features (attempt at seamless looping, really?), and other crap, so it got pretty complicated again. fill_audio_out_buffers() is still full of subtle and buggy logic. Maybe it got worse. On the other hand, maybe there really is some progress. Who knows. Originally, the data flow parts was meant to be in f_output_chain, but due to tricky interactions with the playloop code, it's now in the dummy filter in audio.c. At least this improves the way the audio PTS is passed to the encoder in encoding mode. Now it attempts to pass frames directly, along with the pts, which should minimize timestamp problems. But to be honest, encoder mode is one big kludge that shouldn't exist in this way. This commit should be considered pre-alpha code. There are lots of bugs still hiding.
* DOCS: fix minor issue on the --video-latency-hacks explanationChris Varenhorst2020-08-281-2/+2
|
* Update compile-windows.mdcrackself2020-08-281-1/+1
| | | fix lua5.1-5.2 support with luajit （mxe default upstream lua5.3 ）
* manpage: reorder sentenceGuido Cella2020-08-281-3/+3
|
* f_async_queue: add various helper functionswm42020-08-282-2/+105
| | | | | Shouldn't change the behavior if not used. Will probably be used in a later commit.
* f_async_queue: don't count EOF frames as sampleswm42020-08-282-1/+4
| | | | That's dumb.
* f_async_queue: change reset behaviorwm42020-08-282-3/+15
| | | | | | | | | | | | | | | | Do not make resetting the "access" filters reset the queue itself. This is more flexible, and will be used in a later commit. Also, if the queue is not in the reset state while the input access filter is reset, make it immediately request data again. This is more consistent, because it'll enter the state it "should" be, rather when the filter's process function is called at an (essentially) random point in the future. This means the filter graph will resume work on its own if the queue was not reset before filter reset. This could affect the only current user of f_async_queue, the code for the --vd-queue-enable/--ad-queue-enable feature in f_decoder_wrapper. But it looks like this already uses it in a compatible way.
* filter: add filter priority thingwm42020-08-282-6/+31
| | | | | | | This is a kind of bad hack (with bad implementation) to paint over other problems of the filter system. The main problem is that some filters might be left with pending frames if the filter runner is "paused", which we don't want. To be used in a later commit.
* manpage: slightly improve property list notewm42020-08-281-3/+4
|
* sd_ass: replace deprecated ASS_OVERRIDE_BIT_FONT_SIZEOneric2020-08-282-5/+3
| | | | This requires a slightly more recent libass than before
* osd_libass: don't use deprecated ass_set_aspect_ratioOneric2020-08-281-2/+2
|
* f_demux_in: log EOF "recovery"wm42020-08-271-0/+2
| | | | For debugging.
* f_decoder_wrapper: pass through EOF after EOFwm42020-08-272-0/+8
| | | | | | | | | It's relevant in some obscure corner cases (EDL file that has a segment without audio). Didn't test what's actually going on (is ad_lavc.c behaving wrong? is libavcodec behaving wrong or in an unexpected way? is lavc_process wrong?) and just patched it over with some bullshit, so the fix might be too complicated, and could be reworked at some later point. This sure is a real data flow fuckmess.
* player: fix video paused condition on VO creationwm42020-08-273-2/+8
| | | | | Doesn't take paused_for_cache into account. For consistency; unlikely to matter at all in practice.
* filter: add a helperwm42020-08-272-0/+8
| | | | | Not used yet; probably will, just dumping this to get it out of my sight.
* audio: clarify set_pause() docum