| Commit message (Collapse) | Author | Age |
|---|
| ... | |
| | |
|
| |
|
|
| |
This was accidentally moved together with the cmd stuff.
|
| |
|
|
| |
ffm (ffserver) was removed from ffmpeg.
|
| |
|
|
| |
(Why the fuck are there up to 20 mouse buttons?)
|
| |
|
|
|
|
|
|
|
|
|
| |
The default get_format does exactly do this, so we don't need to
duplicate it.
The only potential problem with this is that the logic doesn't entirely
prevent that the avcodec_default_get_format hw_device_ctx path is
triggered, which would probably work, but has unknown consequences and
interactions. But the way the logic currently works it can't happen,
provided the hwaccel metadata libavcodec provides is correct.
|
| |
|
|
|
|
|
|
| |
Avoids 100% CPU usage due to terminal code retrying read(). Seems like
this was "forgotten" (or there was somehow the assumption poll() would
not signal POLLIN anymore).
Fixes #5842.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
For some reason, the X default modifier map binds shift+tab to
ISO_Left_Tab instead of the regular Tab. So to get Shift+TAB recognized
by mpv, we also need to accept ISO_Left_Tab.
This patch matches what other programs like e.g. Qt do, which treat Tab
and ISO_Left_Tab as the same thing.
God only knows why the distinction exists, and why X decides to mix up
its bindings like that.
Fixes #5849
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes several issues playing back mpegts with video streams marked
as having "still images". For example, see this video which has
frames only every 6s: https://s3.amazonaws.com/tmm1/music-choice.ts
Changes include:
- start playback right away, without waiting for first video frame
- do not consider the sparse video stream in demuxer underrun detection
- do not require multiple video frames for the VO
- use audio as the master stream for demuxer metadata events
- use audio stream for playback time
Signed-off-by: Aman Gupta <aman@tmm1.net>
|
| |
|
|
| |
Signed-off-by: Aman Gupta <aman@tmm1.net>
|
| |
|
|
| |
Needed for the new xdg-wm tiling enums.
|
| |
|
|
|
| |
We already did require it, in order to call set_buffer_scale. This
just makes it error out more gracefully.
|
| |
|
|
| |
Window size should not change if the window has been maximized or tiled.
|
| |
|
|
|
|
|
|
|
|
| |
With the advent of actual HDR devices, my real measured ICC profile has
an "infinite" contrast, since the display is completely off on pure
black inputs. 100k:1 might not be enough, so let's just bump it up to
1m:1 to be safe.
Also, improve the logging in the case that the detected contrast is too
high by default.
|
| | |
|
| |
|
|
|
| |
The old copy is broken with waf-1.9.8, update to the latest commit
(waf-project/waf@5e4b86b81df3b9819738d757eb8d2c8646ef0ede) instead.
|
| | |
|
| |
|
|
|
|
|
| |
This logic has been changed throughout the years, notably in 38ac5d5 and
3bdbf6. Update the documentation to reflect the current state.
Closes #5834.
|
| | |
|
| |
|
|
|
|
| |
This was there originally to detect too-old versions of ffmpeg. We now
only support >= 4.0, so it's not relevant. We just need the dependencies
to be present.
|
| |
|
|
|
|
|
|
|
| |
First fix a memory leak when skipping cursor planes by inverting the
check and putting everything, but the free, in the body.
Then fix a missed drmModeFreePlane by simply copying the fields of the
drmModePlane we are interested in and freeing the drmModePlane struct
early.
|
| |
|
|
|
|
|
| |
Fixes `--ytdl-format="dash-fastly_skyfire-video-363357330+dash-fastly_skyfire_sep-audio-363357330" https://vimeo.com/108650530`
This happened because the video track also had audio available and after
adding it expecting an audio-only track, there were no more tracks with video.
|
| | |
|
| |
|
|
|
|
| |
Could make it behave differently (and leak memory) in certain cases.
Basically, m_option_parse() randomly returns 0 or 1, but most time 1,
with the difference due to legacy reasons that don't matter anymore.
|
| |
|
|
|
|
|
| |
The "if (prop.name)" check is redundant, because an assert above it
implies that it never can be NULL.
Deduplicate some code for initializing the "prop" variable.
|
| | |
|
| |
|
|
|
|
| |
Now both command "descriptions" and runtime command instances are in
cmd.h, which makes sense to me. input.h is now for the actual input
context.
|
| |
|
|
|
|
| |
It doesn't really make sense to keep a separate cmd_list.c file, which
does _not_ contain a command list, but only a few minor helper
functions.
|
| |
|
|
|
| |
Done separately from the cmd.h rename to avoid issues with git being bad
at tracking mixed content and filename changes.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This gets rid of run_command() and its big switch statement, which was
an idiotically big function of almost 1000 lines.
The switch is replaced with a callback per command, and each command is
now implemented in its own function. Command IDs are not needed anymore,
so the mp_command_type enum disappears.
There should be no functional changes, but since this refactors 64
commands, regressions are possible.
The handler() parameter is void*, because in theory the input code is
supposed to be independent of the player core code. For example, you
should be able to reuse the command parser code for some other part of
mpv. In practice, the variable containing command list is defined in the
player core anyway, so you could say this doesn't work. But I'm still
trying to hold onto this idea, so I went with void*.
|
| |
|
|
|
|
|
|
|
|
| |
The plan is to remove the command ID enum. This will happen by replacing
the big switch statement in command.c with dispatching to per-command
callbacks. As preparation, remove uses of the command IDs outside of the
actual dispatching mechanism.
Also remove some instances of checking cmd->def for NULL. We now require
this always to be set.
|
| |
|
|
|
|
|
|
| |
These are old MPlayer commands that were redundant since 2007 or so. In
2013, mpv explicitly deprecated them (actually removed them, but left
this wrapper, which translated them to modern commands). The list was
not extended since 2013, and mpv always warned on the terminal when a
legacy command was used. So it's time to remove it.
|
| |
|
|
| |
Preparation for more changes.
|
| | |
|
| |
|
|
| |
Makes it easier to not break the build by confusing the ifdeffery.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Until recently, ao_lavc and vo_lavc started encoding whenever the core
happened to send them data. Since audio and video are not initialized at
the same time, and the muxer was not necessarily opened when the first
encoder started to produce data, the resulting packets were put into a
queue. As soon as the muxer was opened, the queue was flushed.
Change this to make the core wait with sending data until all encoders
are initialized. This has the advantage that we don't need to queue up
the packets.
|
| |
|
|
|
|
|
|
|
|
|
| |
The user won't want to have those in the video (I think). The core can
sporadically issue redraws, which is what you want for actual playback,
but not in encode mode. vo_lavc can explicitly detect those and skip
them. It only requires switching to a more advanced internal VO API.
The comments in vo.h are because vo_lavc draws to one of the images in
order to render OSD. This is OK, but might come as a surprise to whoever
calls draw_frame, so document it. (Current callers are OK with it.)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The video timing code could just decide that EOF was reached before it
was displayed. This is not really a problem for normal playback (if you
use something like --keep-open it'd show the last frame anyway,
otherwise it'd at best flash it on screen before destroying the window).
But in encode mode, it really matters, and makes the difference between
having one frame more or less in the output file.
Fix this by waiting for the VO before starting the real EOF.
vo_is_ready_for_frame() is normally used to determine when the VO frame
queue has enough space to send a new frame. Since the VO frame queue is
currently at most 1 frame, it being signaled means the remaining frame
was consumed and thus sent to the VO driver. If it returns false, it
will wake up the playloop as soon as the state changes.
I also considered using vo_still_displaying(), but it's not reliable,
because it checks the realtime of the frame end display time.
|
| |
|
|
|
| |
This effectively makes --ocopyts the default. The --ocopyts option
itself is also removed, because it's redundant.
|
| |
|
|
|
|
|
|
|
|
| |
While I'm not sure whether it really works, at least it writes the pass1
log correctly now.
How 2-pass stat output is supposed to interact with the new decode API
is rather fishy. ffmpeg.c does the same, and before this change, the
log was not written on EOF (when at least libvpx actually outputs its
stats).
|
| |
|
|
|
|
| |
With the internal change from stringlist to keyvaluelist, these
sub-options stop working. I don't really care enough to bring them
back. (Order doesn't matter, -del always seemed annoying.)
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Inspired by kmscube, first try to pick the Encoder and CRTC already
associated with the selected Connector, if any. Otherwise try to find
the first matching encoder & CRTC like before.
The previous behavior had problems when using atomic
modesetting (crtc_setup_atomic) when we picked an Encoder & CRTC that
was currently being used by the fbcon together with another Encoder.
drmModeSetCrtc was able to "steal" the CRTC in this case, but using
atomic modesetting we do not seem to get this behavior automatically.
This should also improve behavior somewhat when run on a multi screen
setup with regards to deinit and VT switching (still sometimes you end
up with a blank screen where you previously had a cloned display of
your fbcon)
|
| |
|
|
| |
updated since the plane rename commit
|
| |
|
|
|
|
|
|
|
|
|
| |
Add some properties which where forgotten in crtc_setup_atomic.
In both change to not use DRM_MODE_PAGE_FLIP_EVENT | DRM_MODE_ATOMIC_NONBLOCK
flags. This should make it more similar to the drmSetCrtc which it aims to
replace (take effect directly, and blocking call). This also saves us the
trouble of having to set up a poll to wait for pageflip, which would've been
neccesary with DRM_MODE_PAGE_FLIP_EVENT, in both crtc_setup_atomic and
crtc_release_atomic.
|
| |
|
|
|
|
|
|
|
|
| |
This patch will make sure that the video plane is hidden when unused.
When using high resolution modes, typically UHD, and embedding mpv,
having the video plane sitting in the back when you don't play any video
is eating a lot of memory bandwidth for compositing.
That patch makes sure that the video layer is just disabled before and
after playback.
|
| |
|
|
|
|
|
| |
This commit allows to add atomic modesetting when using the atomic renderer.
This is actually needed when using and osd with a smaller size than screen resolution.
It will also make the drm atomic path more consistent
|
| |
|
|
|
|
|
|
| |
We are currently using primary / overlay planes drm objects, assuming that primary plane is osd and overlay plane is video.
This commit is doing two things :
- replace the primary / overlay planes members with osd and video planes member without the assumption
- Add two more options to determine which one of the primary / overlay is associated to osd / video.
- It will default osd to overlay and video to primary if unspecified
|
| |
|
|
|
|
|
|
|
|
| |
This patch adds
- DRM connector object to atomic context.
- fd property to the drm atomic object as well as a method to read blob type properties.
This allows to ensure that the proper connector is picked up, especially when specifying it
from the commandline, and also allows to make sure we're using the right one when embedding
with interop into an application.
|
wm4
Niklas Haas
Aman Gupta
Rostislav Pehlivanov
sfan5
Bin Jin
Philip Sequeira
Philip Langdale
Anton Kindestam
Ricardo Constantino
TheAMM
Jan Ekström
LongChair