| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
This uses the normal autoprobing rules like "auto", but rejects anything
that isn't flagged as copying data back to system memory.
The chunk in command.c was dead code, so remove it instead of updating
it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The main change is with video/hwdec.h. mp_hwdec_info is made opaque (and
renamed to mp_hwdec_devices). Its accessors are mainly thread-safe (or
documented where not), which makes the whole thing saner and cleaner. In
particular, thread-safety rules become less subtle and more obvious.
The new internal API makes it easier to support multiple OpenGL interop
backends. (Although this is not done yet, and it's not clear whether it
ever will.)
This also removes all the API-specific fields from mp_hwdec_ctx and
replaces them with a "ctx" field. For d3d in particular, we drop the
mp_d3d_ctx struct completely, and pass the interfaces directly.
Remove the emulation checks from vaapi.c and vdpau.c; they are
pointless, and the checks that matter are done on the VO layer.
The d3d hardware decoders might slightly change behavior: dxva2-copy
will not use the VO device anymore if the VO supports proper interop.
This pretty much assumes that any in such cases the VO will not use any
form of exclusive mode, which makes using the VO device in copy mode
unnecessary.
This is a big refactor. Some things may be untested and could be broken.
|
|
|
|
|
|
|
|
|
|
|
| |
Add --taskbar-progress command line option and property which controls taskbar
progress indication rendering in Windows 7+. This option is on by default and
can be toggled during playback.
This option does not affect the creation process of ITaskbarList3. When the
option is turned off the progress bar is just hidden with TBPF_NOPROGRESS.
Closes #2535
|
|
|
|
|
| |
Requested. Will prevent odd layout for playlists with URLs longer than
the screen.
|
|
|
|
|
|
|
|
| |
Introduce hwdec-current and hwdec-interop properties.
Deprecate hwdec-detected, which never made a lot of sense, and which is
replaced by the new properties. hwdec-active also becomes useless, as
hwdec-current is a superset, so it's deprecated too (for now).
|
|
|
|
|
|
|
|
|
| |
For "current" markers on OSD properties like chapter-list. The marker is
now an actual arrow instead of "> ", and non-current entries will have
the same indentation as the current entry.
While I'm not entirely sure about the new look of those lists, it's a
bit better than the visual mess that was before.
|
|
|
|
| |
So we can concatenate them with strings at compile time.
|
|
|
|
|
|
|
|
|
|
| |
Because it's annoying and feels unnatural.
If the B point is set while paused, don't seek. If not paused, it should
properly loop immediately.
In theory there's a chance that it will show at least 1 frame after the
loop point when setting the B point. But let's not care about that.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Commit 382bafcb changed the behavior for ab-loop-a. This commit changes
ab-loop-b so that the behavior is symmetric.
Adjust the OSD rendering accordingly to the two changes.
Also fix mentions of the "ab_loop" command to the now preferred
"ab-loop".
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Calculate the buffering percentage in the same code which determines
whether the player is or should be buffering. In particular it can't
happen that percentage and buffering state are slightly out of sync due
to calling DEMUXER_CTRL_GET_READER_STATE and reusing it with the
previously determined buffering state.
Now it's also easier to guarantee that the buffering state is updated
properly.
Add some more verbose output as well.
(Damn I hate this code, why did I write it?)
|
|
|
|
| |
Possibly slightly more useful/intuitive.
|
|
|
|
|
|
|
| |
And remove the same thing from the client API code.
The command.c code has to deal with many specialized M_PROPERTY_SET_*
actions, and we bother with a subset only.
|
|
|
|
| |
In that case, it merely changes the underlying option value.
|
|
|
|
|
|
| |
Just a bridge to the option.
(Did I ever mention that I hate the property/option separation.)
|
|
|
|
|
|
|
|
| |
Instead of having a separate for each, which also requires separate
additional caching in the demuxer. (The demuxer adds an indirection,
since STREAM_CTRLs are not thread-safe.)
Since this includes the cache speed, this should fix #3003.
|
|
|
|
|
|
| |
Enables runtime change of the option.
Fixes #2994.
|
|
|
|
|
| |
Also change the property to an int, since using double is questionable
and pointless.
|
|
|
|
|
|
|
| |
Should reflect I/O speed.
This could go into the terminal status line. But I'm not sure how to put
it there, since it already uses too much space, so it's not there yet.
|
|
|
|
|
| |
mp_switch_track() doesn't do it automatically for whatever reason, so do
it here.
|
|
|
|
|
|
|
| |
This pause stuff is bothersome and is needed only for a few corner-
cases. This commit removes it from the demuxer public API and replaces
it with a demux_run_on_thread() function and refactors the code which
needed demux_pause(). The next commit will change the implementation.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Changing the byte stream position without cooperation of the demuxer
seems a bit insane, and is certainly useless. A user should do factor
seeks instead. For formats like ts, this will actually translate to byte
seeks, while treating the rest of the playback chain a bit more
gracefully. With this argument, remove write access to this property.
If someone really complains, proper byte seeks could be added as seek
mode (although I'm going to need a convincing argument for this).
Read access changes too, but in a more subtle way.
|
|
|
|
|
|
| |
No need to have them everywhere. The only exception/annoyance is
MAX_OSD_PARTS, which is now basically duplicated (and at runtime
initialization is checked with an assert()).
|
| |
|
|
|
|
|
| |
Also change decoder-list (for the sake of sharing the underlying code
for both properties).
|
|
|
|
| |
Was printed only with "mpv -h" or so.
|
|
|
|
|
|
|
| |
Was only available via --vd=help and --ad=help (i.e. not at all via
client API). Not bothering with separating audio and video codecs, since
this list isn't all that useful anyway in general. If someone complains,
a type field could be added.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Export a number of container fields, which may or may not be useful in
some scenarios. They are explicitly marked as originating from the
demuxer, in order to make it explicit that they might be unreliable.
I'd actually like to remove all other cases where container information
is exported, but those numerous cases are going to be somewhat hard to
deprecate.
Also, not directly related, export the description of the currently
active decoder. (This has been requested before.)
|
|
|
|
|
|
|
| |
It was just dead code.
Also fixes the stream-open-filename property, which is supposed to be
read-only if a file was already opened.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Unfortunately I see no better solution.
The refresh seek is skipped if the amount of buffered audio is not
overly huge.
Unfortunately softvol af_volume insertion still can cause this issue,
because it's outside of the normal dynamic filter chain changing code.
Move the video refresh call to reinit_video_filters() to make it more
uniform along with the audio code.
|
|
|
|
|
|
| |
Apparently useful for window embedding.
Fixes #2750.
|
|
|
|
|
|
|
| |
For bitmap subs, implement it properly. For libass, you need newest git
master.
Fixes #2791.
|
|
|
|
|
|
| |
Also remove the unused function argument.
Fixes #2784.
|
|
|
|
|
| |
Basically, just make it append " (original)" if the original aspect
ratio is selected.
|
|
|
|
| |
Don't mind me.
|
|
|
|
|
|
|
| |
We just need to provide an entrypoint for it, and move the main init
code to a separate function. This gets rid of the messy video chain full
reinit in command.c, which completely destroyed and recreated the video
state for the purpose of mid-stream hw/sw switching.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This seems generally easier when using libmpv (and was already requested
and implemented before: see commit 327a779a; it was reverted some time
later).
With the weird internal logic we have to deal with, in particular the
--softvol=no case (using system volume), and using the audio API's mixer
(--softvol=auto on some systems), we still can't avoid all glitches and
corner cases that complicate this issue so much. The API user is either
recommended to use --softvol=yes or auto, or to watch the new
mixer-active property, and assume the volume/mute properties have
significant values if the mixer is active.
Remaining glitches:
- changing the volume/mute properties has no effect if no internal mixer
is used (--softvol=no) and the mixer is not active; the actual mixer
controls do not change, only the property values
- --volume/--mute do not have an effect on the volume/mute properties
before mixer initialization (the options strictly are only applied
during mixer init)
- volume-max is 100 while the mixer is not active
|
|
|
|
| |
Similar to vf-command. Requested. Untested.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
Similar to the video path. dec_audio.c now handles decoding only. It
also looks very similar to dec_video.c, and actually contains some of
the rewritten code from it. (A further goal might be unifying the
decoders, I guess.)
High potential for regressions.
|
|
|
|
| |
Fixes #2729.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Eventually we want the VO be driven by a A->V filter, so a decoder
doesn't even have to exist. Some features definitely require a decoder
though (like reporting the decoder in use, hardware decoding, etc.), so
for each thing which accessed d_video, it has to be redecided if and how
it can access decoder state.
At least the "framedrop" property slightly changes semantics: you can
now always set this property, even if no video is active.
Some untested changes in this commit, but our bio-based distributed
test suite has to take care of this.
|
|
|
|
| |
The same is going to happen to d_video and d_audio later.
|
|
|
|
|
|
|
| |
Not bothering with anything advanced, so we just show "(original)" if
the video-aspect property/option is reset.
Fixes #2722.
|
|
|
|
|
|
|
|
|
|
|
| |
This moves some code related to decoding from video.c to dec_video.c,
and also removes some accesses to dec_video.c from the filtering code.
dec_video.ch is starting to make sense, and simply returns video frames
from a demuxer stream. The API exposed is also somewhat intended to be
easily changeable to move decoding to a separate thread, if we ever want
this (due to libavcodec already being threaded, I don't see much of a
reason, but it might still be helpful).
|
| |
|
|
|
|
|
|
|
|
|
| |
The aspect ratio calculations are cached (mainly so that aspect ratio
related messages are not logged on every frame). The cache is not clared
anymore when video filters are reconfigured, but changing the
video-aspect-ratio property relied on it. Make it explicit.
Fixes #2714.
|
|
|
|
|
| |
If it is defined, which it rarely is (e.g. mpegts streams)
this is the preferred title information.
|
|
|
|
|
|
|
|
| |
The binding is similar to the tv-binding, just with capital letters.
Switching the dvb-channel-name property compared to dvb-channel
means the channel-name is shown on-screen when switching instead of
"dvb-channel (error)" otherwise,
and switching anyways happens without changing the card.
|
|
|
|
|
|
| |
Channel switching is treated inside the global DVB state
by now. Anyways the last switching direction is not really useful
and of no interest inside the player.
|
|
|
|
|
|
|
|
|
| |
On read, it returns the name of the current DVB program,
on write, it triggers a channel-switch to the program
if it is found in the channel list of the currently active card.
Compared to the dvb-channel property which already exists
and is a pair of integers (card + channel number) this has the limitation
of not switching the card, but is probably of much more common use.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Lots of noise to remove the vfilter/vo fields from dec_video.
From now on, video filtering and output will still be done together,
summarized under struct vo_chain.
There is the question where exactly the vf_chain should go in such a
decoupled architecture. The end goal is being able to place a "complex"
filter between video decoders and output (which will culminate in
natural integration of A->V filters for natural integration of
libavfilter audio visualizations). The vf_chain is still useful for
"final" processing, such as format conversions and deinterlacing. Also,
there's only 1 VO and 1 --vf option. So having 1 vf_chain for a VO seems
ideal, since otherwise there would be no natural way to handle all these
existing options and mechanisms.
There is still some work required to truly decouple decoding.
|
|
|
|
|
|
|
|
|
|
| |
Instead of handling this on filter chain reinit, do it directly after
the decoder. This makes the code less entangled. In particular, this
gets rid of the really weird "override params" concept in the video
filter code.
The last_format/fixed_formats have some redundance with decoder_output,
but unfortunately the latter has a slightly different use.
|
|
|
|
|
|
|
|
|
|
| |
This is mainly a refactor. I'm hoping it will make some things easier
in the future due to cleanly separating codec metadata and stream
metadata.
Also, declare that the "codec" field can not be NULL anymore. demux.c
will set it to "" if it's NULL when added. This gets rid of a corner
case everything had to handle, but which rarely happened.
|
|
|
|
| |
This change helps avoiding conflict with talloc.h from libtalloc.
|
|
|
|
|
| |
lrint() pretty much does what ROUND() is supposed to do, but it's more
precise.
|
|
|
|
|
|
|
|
|
| |
For files with only 1 chapter, the "cycle" command was ignored. Reenable
it, but don't let it terminate playback of the file.
For the full story, see #2550.
Fixes #2550.
|
|
|
|
|
|
|
|
|
| |
See #2609:
"When eof is reached it would be shown on the OSD and in the console.
Next try seeking to the middle. Seeking to the middle of the file will
only result in the OSD message being updated. Lua seems to fail to
observe the change in the property until the video is unpaused."
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The "script-binding" command is used by the Lua scripting wrapper to
register key bindings on the fly. It's also the only way to get fine-
grained information about key events (such as separate key up/down
events). This information is sent via a "key-binding" message when the
state of a key changes.
Extend it to send name of the mapped key itself. Previously, it was
assumed that the user just uses an unique identifier for the binding's
name, so it wasn't needed. With this change, a user can map exactly the
same command to multiple keys, which is useful especially with the next
commit.
Part of #2612.
|
|