| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
| |
The comment says that it wakes up the main thread if 50% has been
played, but in reality the value was 0.74/2 => 37.5%. Correct this. This
probably changes little, because it's a very fuzzy heuristic in the
first place.
Also move down the min_wait calculation to where it's actually used.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
mp3 has a hack lowering the probescore for format detection. This is
because detecting mp3s is hard due to their nature, and the fact that
ID3v2 tags are sometimes several megabytes big.
When playing mp3 from network, the mime-type is usually set, and that
matches the format hack entry meant for webradios, overriding the normal
mp3 entry. This can lead to network mp3s not being detected. Lower the
network case to the same probescore as on-disk mp3s. The difference is
that for network mp3s, we don't load the full probe-buffer, and we lower
the amount of audio the demuxer will read to collect data on opening
(0.5 seconds instead of typically 5 seconds).
|
|
|
|
| |
It's in seconds, but the code used it as sample count.
|
| |
|
| |
|
|
|
|
|
| |
They were used for printing slave mode stuff, which was recently
removed.
|
|
|
|
|
| |
This shouldn't change anything functionally, except that it buffers 1
frame less in the first-field deinterlacing mode.
|
|
|
|
|
|
|
| |
This was a minor code duplication between vf_vdpaupp.c and vo_vdpau.c.
(In theory, we could always require using vf_vdpaupp with vo_vdpau, but
I think it's better if vo_vdpau can work standalone.)
|
|
|
|
| |
There's no reason why these should be separate.
|
| |
|
|
|
|
|
|
|
| |
Also remove MSGL_SMODE and friends.
Note: The indent in options.rst was added to work around a bug in
ReportLab that causes the PDF manual build to fail.
|
| |
|
|
|
|
|
| |
--dvdangle → --dvd-angle
--tvscan → --tv-scan
|
|
|
|
|
|
|
|
|
| |
--msgcolor → --msg-color
--msglevel → --msg-level
--msgmodule → --msg-module
--msgtime → --msg-time (also document this one)
--playing-msg → --term-playing-msg
--status-msg → --term-status-msg
|
|
|
|
|
|
|
|
|
|
|
| |
Renamed options:
--aspect → --video-aspect
--fstype → --x11-fstype
--native-fs → --fs-missioncontrol
--name → --x11-name
Renamed properties:
aspect → video-aspect
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Renamed options:
--audiofile → --audio-file
--audiofile-cache → --audio-file-cache
--channels → --audio-channels
--format → --audio-format
--srate → --audio-samplerate
Renamed properties:
samplerate → audio-samplerate
channels → audio-channels
|
|
|
|
|
|
|
|
|
| |
--ass → --sub-ass
--autosub → --sub-auto
--autosub-match → --sub-auto-match
--sub → --sub-file
--subcp → --sub-codepage
--subfps → --sub-fps
|
|
|
|
|
|
|
|
|
|
|
| |
--ar → --input-appleremote
--consolecontrols → --input-terminal
--media-keys → --input-media-keys
--joystick → --input-joystick
--lirc → --input-lirc
--lircconf → --input-lirc-conf
--mouse-movements → --input-cursor
--right-alt-gr → --input-right-alt-gr
|
|
|
|
|
| |
Better to tell users straight away that mpv should not be treated
as just another MPlayer.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When loading a video, and a script reacts to MPV_EVENT_VIDEO_RECONFIG,
and the script inserts a video filter, the first frame can be skipped.
This happens simply because the first frame is (usually) still queued in
the video filter chain, and changing the filter chain will drop all
queued frames. So this is just a corner case that just happens in a
weird situation.
But it's still annoying when having such a script, and starting
something where the first frame is very visible, and not starting in
paused mode. (All in all, a corner case.) Do this by immediately queuing
1 filtered frame to the VO immediately after reconfig, instead of
leaving it to the video loop doing it as "incremental" work. Simply
fallthrough to the next case. We must not overwrite "r" in this case,
because that contains the current status.
Note that the first frame will not be filtered using the inserted
filter.
|
|
|
|
|
|
|
|
|
|
| |
This wasn't really fine, and could (perhaps) cause weird corner cases on
reinit or when the player was paused.
Before eb9d20, video_left was also set to true if vo->frame_loaded was
set, and this variable basically indicated whether the previous
update_video() call was successful. This was overlooked when changing
everything. Simply always call update_video(), it should be equivalent.
|
|
|
|
| |
Cosmetic change, reduce the diff of the following commit.
|
|
|
|
|
|
| |
This was recently either changed or clarified in vapoursynth.
Pass the aspect ratio as pixel aspect to VS.
|
|
|
|
|
|
| |
This can happen when the input stream is somehow blocking on network,
and the user still send input in one way or another, and one of the
commands is a compound command ("cmd a ; cmd b").
|
|
|
|
| |
Oops. Sigh.
|
| |
|
|
|
|
| |
This seems a bit silly, but the way vf_vdpaupp works, this is cleaner.
|
| |
|
| |
|
|
|
|
|
|
| |
Apparently the value of a pointer is "indeterminate" after a free()
call, even if you never dereference the pointer after the free. Since
talloc_free() calls free(), this applies here.
|
|
|
|
| |
Filter reconfig can now happen a few frames before VO reconfig.
|
|
|
|
|
|
|
| |
This is because Lua scripts creating key bindings create 2 input
sections per script.
Probably fixes #759.
|
|
|
|
|
|
|
|
|
| |
This affects the return value of mp.script_name, the "client name"
(what's returned by mpv_client_name()) and all associated features, as
well as the mpv terminal output module prefix when scripts print
something.
As discussed in #748.
|
|
|
|
|
|
|
| |
Change how the video decoding loop works. The structure should now be a
bit easier to follow. The interactions on format changes are (probably)
simpler. This also aligns the decoding loop with future planned changes,
such as moving various things to separate threads.
|
|
|
|
|
| |
${filename} didn't make much sense, since that doesn't include the path
components, and can be otherwise mangled.
|
|
|
|
|
| |
Now the video filter code handles these explicitly, which should
increase robustness (or at least find bugs earlier).
|
|
|
|
|
|
|
|
|
| |
vf_fix_img_params() takes care of overwriting image parameters that are
normally not set correctly by filters. But this makes no sense for input
images. So instead, check that the input is correct.
It still has to be done for the first input image, because that's used
to handle some overrides (see video_reconfig_filters()).
|
|
|
|
|
|
|
| |
These replace vf_read_output_frame(), although we still emulate that
function. This change is preparation for another commit (and this is
basically just to reduce the diff and signal/noise ratio in that
commit).
|
|
|
|
| |
Preparation (and simplification) for following commits.
|
|
|
|
|
| |
Nota that this flag is not set for other auto-inserted filters (like
deinterlacing or rotation).
|
|
|
|
|
|
| |
Basically, if we feed the filter a new image even after the EOF state
has been reached (e.g. because the input stream "recovered"), we want
the filter to restart, instead of returning an error forever.
|
|
|
|
|
| |
Currently, only the configured format is accepted, so assert that the
playback core code (which handles format changes) is correct.
|
|
|
|
|
|
|
| |
(Again.)
This was caused by mp_image_set_params() not properly copying d_w/d_h,
because mp_image_set_size() resets them.
|
|
|
|
|
|
|
|
|
|
|
| |
Some non-deinterlacing filters (potentially denoising) also use
additional frames for filtering. The vdpau docs suggest providing at
least 1 future and 2 past _fields_, which means we need to provide 1
past frame (the future field is already the other field of the current
field, and both fields are in the same frame).
We can easily achieve this by buffering an additional frame in the non-
deint case.
|
|
|
|
|
| |
Since vdpau_mixer.c initializes the YUV conversion using the mp_image
flags, these images should have all flags set properly.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove the special casing of vo_vdpau vs. other VOs. Replace the
complicated interaction between vo.c and vo_vdpau.c with a simple queue
in vo.c. VOs other than vdpau are handled by setting the length of the
queue to 1 (this is essentially what waiting_mpi was).
Note that vo_vdpau.c seems to have buffered only 1 or 2 frames into the
future, while the remaining 3 or 4 frames were past frames. So the new
code buffers 2 frames (vo_vdpau.c requests this queue length by setting
vo->max_video_queue to 2). It should probably be investigated why
vo_vdpau.c kept so many past frames.
The field vo->redrawing is removed. I'm not really sure what that would
be needed for; it seems pointless.
Future directions include making the interface between playloop and VO
simpler, as well as making rendering a frame a single operation, as
opposed to the weird 3-step sequence of rendering, drawing OSD, and
flipping.
|
| |
|
|
|
|
|
| |
This is a horrible hack to keep compatibility with the vo_vdpau deint
sub-option.
|
|
|
|
|
|
|
| |
Give up on the deint_filters[] array, and probe using explicit code
instead. Add additional checks to test the pixel format to avoid
annoying warnings when a hardware deinterlacer is inserted when the
current video chain is obviously incompatible.
|
|
|
|
|
|
| |
This restores the capability of enabling deinterlacing with the
'cycle deinterlace' command with vo_vdpau, and also makes it work
with vo_opengl.
|
|
|
|
|
| |
Basically makes the 'D' key work again. (But only if the filter is
already inserted.)
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The previous commits changed vo_vdpau so that these options are set by
vf_vdpaupp, and the corresponding vo_vdpau were ignored. But for
compatibility, keep the "old" options working.
The value of this is questionable - maybe the vo_vdpau options should
just be removed. For now, at least demonstrate that it's possible.
The "deint" suboption still doesn't work, because the framerate doubling
logic required for some deint modes was moved to vf_vdpaupp. This
requires more elaborate workarounds.
|
|
|
|
| |
So a caller can override the filter options dictated by vf_vdpaupp.
|
|
|
|
|
|
|
|
|
|
| |
This is slightly incomplete: the mixer options, such as sharpen and
especially deinterlacing, are ignored. This also breaks automatic
enabling of interlacing with 'D' or --deinterlace. These issues will be
fixed later in the following commits.
Note that we keep all the custom vdpau queue stuff. This will also be
simplified later.
|
|
|
|
|
|
|
| |
This uses mp_vdpau_mixer_render(). The benefit is that it makes vdpau
deinterlacing just work. One additional minor advantage is that the
video mixer creation code is factored out (although that is a double-
edged sword).
|
|
|
|
|
|
|
| |
So you can use vdpau deinterlacing without using vdpau hardware
decoding.
vf_vavpp does something similar.
|
|
|
|
|
|
|
|
|
|
|
| |
This factors out some code from vo_vdpau.c, especially deinterlacing
handling. The intention is to use this for vo_vdpau.c to make the logic
significantly easier, and to use it for vo_opengl (gl_hwdec_vdpau.c) to
allow selecting deinterlace and postprocessing modes.
As of this commit, the filter actually does nothing, since both vo_vdpau
and vo_opengl treat the generated images as normal vdpau images. This
will change in the following commits.
|
| |
|
|
|
|
| |
This field will also removed in the future.
|
| |
|
|
|
|
|
| |
The filters don't always print an error on their own, and printing an
error is better than silently dropping the frame.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
It now inserts no filters and does nothing until the hot-key is pressed.
This makes it more suitable to be put in ~/.mpv/lua.
When the hot-key is pressed, it now inserts the cropdetect filter and
waits 1 second (or a --lua-opts specified duration) before gathering
the cropdetect metadata and inserting the appropriate crop filter. A
second press of the hotkey removes the crop.
|
|
|
|
|
|
| |
It might have been nice not to do this so that metadata could
accumulate accross seeks, but it seems libavfilter looses its copy
anyway on recreate_graph.
|
|
|
|
|
|
| |
lavfi would segfault due to a NULL dereference if it was asked for its
metadata and none had been allocated (oops). This happens for libav
which has no concept of filter metadata.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 5e4e248 added a mp_image_params field to mp_image, and moved many
parameters to that struct. display_w/h was left redundant with
mp_image_params.d_w/d_h. These fields were supposed to be always in
sync, but it seems some code forgot to do this correctly, such as
vf_fix_img_params() or mp_image_copy_attributes(). This led to the
problem in github issue #756, because display_w/_h could become
incorrect.
It turns out that most code didn't use the old fields anyway. Just
remove them. Note that mp_image_params.d_w/d_h are supposed to be always
valid, so the additional checks for 0 shouldn't be needed. Remove these
checks as well.
Fixes #756.
|
|
|
|
|
|
|
| |
In theory, returning the screenshot with original pixel aspect would
allow avoiding scaling them with image formats that support non-square
pixels, but in practice this isn't used anyway (nothing seems to
understand e.g. jpeg aspect ratio tags).
|
| |
|
|
|
|
|
|
|
| |
Apparently, the 3rd (2nd) parameter to string.translate() function was
removed.
Also, make_abs() had a mistake - not sure how this passed testing.
|
|
|