1
0
mirror of https://github.com/mpv-player/mpv synced 2024-12-25 00:02:13 +00:00
Commit Graph

44369 Commits

Author SHA1 Message Date
wm4
085dfdea32 command: rename framedrop properties
"drop-frame-count" -> "decoder-frame-drop-count"
"vo-drop-frame-count" -> "frame-drop-count"

This gets rid of the backwards "drop-frame" part in the name.

Maybe calling the new property "frame-drops" would be better, but there
are already a bunch of similar properties that end in "-count".
2017-01-20 17:01:29 +01:00
wm4
fd203ff16a options: refacactor how --opengl-dwmflush is declared
Same deal as previous commit, except this time we just readd it as lone
global option, and read it directly.
2017-01-20 14:03:34 +01:00
wm4
d890e0731c options: refactor how --opengl-dcomposition is declared
vo_opengl used to have it as sub-option, which made it very hard to pass
down option values to backends in a generic way (even if these options
were completely backend-specific). For --opengl-dcomposition we used a
VOFLAG to deal with this. Fortunately, sub-options are gone, and we can
just add it as global option.

Move the option to context_angle.c and add it as global option. I
thought about adding a mechanism to let backends declare options, which
would get magically picked up my m_config instead of having to add them
to the global option list manually (similar to VO vo_driver.options),
but decided against this complexity just for 1 or 2 backends. Likewise,
it could have been added as a single option to avoid the boilerplate of
an option struct, but then again there are probably going to be more
angle suboptions, and it's cleaner.
2017-01-20 13:40:59 +01:00
wm4
a35a5bb5f3 x11: pseudo HiDPI scaling
Scale the window by the assumed DPI scaling factor, using 96 DPI as
base. For example, a screen that reports 192 DPI is assumed to have a
DPI scale factor 2. The window will then be created with twice the size.

For robustness reasons, we accept only integer DPI scales between 1 and
9. We also error out if the X and Y scales are very different, as this
most likely indicates a multiscreen system with botched size reporting.

I'm not sure if reading the X server's DPI is such a good idea - maybe
the Xrdb "Xft.dpi" value should be used instead. The current method
follows what xdpyinfo does.

This can be disabled with --hidpi-window-scale=no.
2017-01-19 16:31:54 +01:00
wm4
4adfde5dd1 options: drop deprecated --sub-codepage syntax 2017-01-19 15:46:59 +01:00
wm4
13add62cf0 options: drop deprecated --vd/--ad codecs selection features
Only simple selection works now. Using "-" to terminate codec selection
remains in the code (might get undeprecated).
2017-01-19 15:38:58 +01:00
Akemi
717ee3ddba cocoa: don't constrain window frame for fullscreen
our constrainFrameRect prevents our window from positioning itself ontop
of the menubar, which is unwanted for a fullscreen window. this always
positioned our window vertically at -22/-23pt when going into fullscreen
because of the menubar. this bug doesn't show on newer versions of OS X
since the various flags we set force the window position. on OS X 10.9
though the fullscreen window was shifted 22pt downwards. even though
this bug doesn't show on newer OS X versions, it should still be fixed
for a possible behaviour changes in future version.

Fixes #4044
2017-01-19 14:59:51 +01:00
Akemi
9490b628c5 cocoa: don't init displaylink on reconfig
everytime we switched to a new video file a new displaylink was
initialised and started, but the old one was not stopped and released
beforehand. this lead to several displaylink callback calls per swap,
depending on how many files were switched beforehand. moving the
displaylink init call to the cocoa init functions will ever only init
one displaylink.

Fixes #4031
2017-01-19 14:58:15 +01:00
Akemi
fe02e5023c cocoa: move updateBorder method to the protocol
we are calling the method on a NSWindow object that may not respond to
that call, since its a method of MpvVideoWindow. add the method to our
protocol and rename that protocol to reflect the change.
2017-01-19 14:54:22 +01:00
Akemi
202f9b218a cocoa: properly recover from toggleFullscreen fail
in some circumstances cocoa isn't able to enter or exit fullscreen but
we still set window sizes and flags accordingly. this leaves us in a
hanging state between fullscreen and window. it also prevents the
toggleFullscreen method and its events to work properly afterwards. in
that state it's impossible to enter or exit this 'semi-fullscreen'.
add a proper fallback to recover from this state.

Fixes #4035
2017-01-19 14:52:51 +01:00
Akemi
4fe45fb3a1 cocoa: fix window size in certain circumstances
a combination of starting from bundle and fullscreen used the standard
window size (960x480) from the pseudo GUI instead of the wanted video
size.
2017-01-19 14:51:11 +01:00
wm4
8cbb2b5e9a ad_spdif: log avformat errors 2017-01-19 12:44:28 +01:00
wm4
880bf54d7e player: actually let cache readahead after opening demuxer for prefetch
Disabling cache readahead by default until at least 1 track is selected
is mainly for external files and such, where you don't want them to use
up resources until they're actually used.

It doesn't make sense to disable the cache for the demuxer opened for
prefetch. Also, it's fine to let it do that for the main file too (doing
or not doing it is of little consequence). That saves us from having to
distinguish them.
2017-01-19 08:00:19 +01:00
wm4
06c8ec27f6 player: also log if completely prefetched URL is discarded
Seems like quite an important/interesting case?
2017-01-19 07:56:49 +01:00
wm4
e277fadd60 player: add prefetching of the next playlist entry
Since for mpv CLI, the player state is a singleton, full prefetching is
a bit tricky. We do it only on the demuxer layer.

The implementation reuses the old "open thread". This means there is
significant potential for regressions even if the new option is not
used. This is made worse by the fact that I barely tested this code.

The generic mpctx_run_reentrant() wrapper is also removed - this was its
only user, and its remains become part of the new implementation.
2017-01-18 19:02:50 +01:00
wm4
c54c3b6991 player: restructure cancel callback
As preparation for file prefetching, we basically have to get rid of
using mpctx->playback_abort for the main demuxer (i.e. the thing that
can be prefetched). It can't be changed on a running demuxer, and always
using the same cancel handle would either mean aborting playback would
also abort prefetching, or that playback can't be aborted anymore.

Make this more flexible with some refactoring.

Thi is a quite shitty solution if you ask me, but YOLO.
2017-01-18 17:52:05 +01:00
wm4
04858c0b83 player: move some minor demuxer setup code
In particular, move demux_set_ts_offset() out of the loader thread.
There's no discernible reason for that, probably.
2017-01-18 16:48:47 +01:00
wm4
e7d902bdc0 vo: log timings around flipping/waiting
Found those useful.
2017-01-18 12:14:26 +01:00
wm4
c522d0dfbd ad_spdif: fix obscure cases of AC3 passthrough
Apparently you set the native sample rate when passing through AC3.
This fixes passthrough with 44100 Hz AC3.

Avoid opening a decoder for this and only open the parser. (Hopefully
DTS will also support this some time in the future or so - having to
open a decoder just to get the profile is dumb.)
2017-01-18 10:22:28 +01:00
wm4
da8011c5df vaapi: detect new API on FFmpeg too, and disable it by default
Since the only way to detect the API is by a version check, this had to
wait until the patches were actually pushed to FFmpeg git (which now
happened).

Since this does not include the new magic GPU memcpy libavutil function
yet, the new vaapi code would be slower if copy mode (like vaapi-copy)
is used. This would be quite bad to use by default, so check for the
function, and if not present, disable the new vaapi code. This
effectively disables it by default on FFmpeg.

(We assume that if the new GPU memcpy exists, vaapi's AVHWFramesContext
implementation will use it.)
2017-01-18 08:17:29 +01:00
wm4
398e2d5d42 vaapi: fix va_surface_get_uncropped_size() for libavutil surfaces
Fixes vf_vavpp crashing with the new vaapi decode API.
2017-01-18 08:17:10 +01:00
wm4
a38283d5d9 vaapi: we don't need SSE intrinsics with the new API
libavutil does this for us. Although the new vaapi decode API does not
strictly introduce or even need av_image_copy_uc_from(), it's implied
that it will be present if the new decode API is present - even if it's
not, we can't use our own SSE code with it anyway.
2017-01-17 15:48:56 +01:00
wm4
9d68d8fb0f vo_opengl, vo_opengl_cb: better hwdec interop backend selection
Introduce the --opengl-hwdec-interop option, which replaces
--hwdec-preload. The new option allows explicit selection of the interop
backend.

This is relatively complex, and I would have preferred not to add this,
but it's probably useful to debug certain problems. In exchange, the
"new" option documents that pretty much any but the simplest use of it
will not be forward compatible.
2017-01-17 15:48:56 +01:00
wm4
e94890a5d6 vo_opengl_cb: cleanup messy option synchronization
Replace the old code, that played games to evade thread-safety issues,
with newer thread-safe option access functions.

This also means mp_opengl_create() doesn't need to cache the hwdec
settings anymore. (They're applied in mpv_opengl_cb_init_gl() instead.)
2017-01-17 15:48:56 +01:00
wm4
4b3b3a045a vdpau: reject decoding of non-4:2:0
Tried to decode a High 4:2:2 file, since libavcodec code seemed to
indicate that it's supported. Well, it decodes to garbage.

I couldn't find out why ffmpeg.c actually appears to reject this
correctly. The API seems to be fine with, just that the output is
garbage.

Add a hack for now.
2017-01-17 15:48:56 +01:00
wm4
9d69eae162 vd_lavc: always fail decoding immediately if copying hw surface fails
Successful decoding of a frame resets ctx->hwdec_fail_count to 0 - which
us ok, but prevents fallback if it fails if --vd-lavc-software-fallback
is set to something higher than 1.

Just fail it immediately, since failing here always indicates some real
error (or OOM), not e.g. a video parsing error or such, which we try to
tolerate via the error counter.
2017-01-17 15:48:56 +01:00
wm4
ff9f2c4b6e vdpau: use libavutil for surface allocation during decoding
Use the libavutil vdpau frame allocation code instead of our own "old"
code. This also uses its code for copying a video surface to normal
memory (used by vdpau-copy).

Since vdpau doesn't really have an internal pixel format, 4:2:0 can be
accessed as both nv12 and yuv420p - and libavutil prefers to report
yuv420p. The OpenGL interop has to be adjusted accordingly.

Preemption is a potential problem, but it doesn't break it more than it
already is.

This requires a bug fix to FFmpeg's vdpau code, or vdpau-copy (as well
as taking screenshots) will fail. Libav has fixed this bug ages ago.
2017-01-17 15:48:56 +01:00
wm4
cda31b71de vaapi: move AVHWFramesContext setup code to common code
In a way it can be reused. For now, sw_format and initial_pool_size
determination are still vaapi-specific. I'm hoping this can be eventally
moved to libavcodec in some way. Checking the supported_formats array is
not really vaapi-specific, and could be moved to the generic code path
too, but for now it would make things more complex.

hw_cuda.c can't use this, but hw_vdpau.c will in the following commit.
2017-01-17 15:48:56 +01:00
William Woodruff
a4cdd8bb82 lua: close directory after reading its entries
Fixes #4045.
2017-01-17 08:22:13 +01:00
wm4
9850932722 build: prefix hwaccel decoder wrapper filenames with hw_
Should have done this a long time ago.

d3d.c remains as it is, because it's just a bunch of helper functions.
2017-01-17 08:11:12 +01:00
wm4
64041f963e cuda: fix 10 bit decoding
Messy mess. Unsure whether this will be resolved properly in FFmpeg.
2017-01-16 19:58:40 +01:00
Ricardo Constantino
fb6481ecb5
stream_bluray: use proper 0-based idx
Even though the title list code was copied from FFmpeg/libbluray,
I didn't check that mpv used 0-based title indexing.

$ mpv bd://1 --bluray-device=. --msg-level=bd=v
[bd] Opening bd://
[bd] List of available titles:
[bd] idx:   1 duration: 00:00:36 (playlist: 00000.mpls)
[bd] idx:   2 duration: 01:31:30 (playlist: 00001.mpls)
[bd] idx:   3 duration: 00:00:50 (playlist: 00003.mpls)

bd://1 actually opens idx 2 from the list, not 1.
bd://mpls/1 opens playlist 00001.mpls as expected.

With this commit:
$ mpv bd://1 --bluray-device=. --msg-level=bd=v
[bd] Opening bd://
[bd] List of available titles:
[bd] idx:   0 duration: 00:00:36 (playlist: 00000.mpls)
[bd] idx:   1 duration: 01:31:30 (playlist: 00001.mpls)
[bd] idx:   2 duration: 00:00:50 (playlist: 00003.mpls)

should play the expected idx 1.
2017-01-16 16:03:15 +00:00
wm4
083e470091 manpage: add comment about --alpha being broken on X11/EGL/Mesa 2017-01-16 16:47:57 +01:00
wm4
1b1771f2a7 video: support filtering hardware frames via libavfilter
Requires a bunch of hacks:
- we access AVFilterLink.hw_frames_ctx. This is not a public API in
  FFmpeg and Libav. Newer FFmpeg provides an accessor
  (av_buffersink_get_hw_frames_ctx), but it's not available in Libav or
  the current FFmpeg release or Libav. We need this value after filter
  graph creation, so We have no choice but to access this.
  One alternative is making filter creation and format negotiation
  fully lazy (i.e. delay it and do it as filters are output), but this
  would be a huge change.
  So for now, we knowingly violate FFmpeg's and Libav's ABI and API
  constraints because they don't provide anything better.
  On newer FFmpeg, we use the (quite ugly) accessor, though.
- mp_image_params doesn't (and can't) have a field for the frames
  context AVBufferRef. So we pass it via vf_set_proto_frame(), and even
  more hacks.
- if a filter needs a hw context, but we haven't created one yet
  (because normally we create them lazily), it will fail at init.
- we allow any hw format now, although this could go horrible wrong.

Why all this effort? We could move hw deinterlacing filters etc. to
FFmpeg, which is a very worthy goal.
2017-01-16 16:10:39 +01:00
wm4
91fb7078e2 vf_lavfi: switch to AVBufferSrcParameters
Instead of using the awful older "API" that passed the parameters
formatted as string. AVBufferSrcParameters is also a prerequisite for
hardware frame filtering support.
2017-01-16 16:10:39 +01:00
wm4
8a23892d04 vo_opengl: hwdec_cuda: add yuv420p support
Because it allows easier testing of filters + hwdec.

Make the texture setup code a bit more generic so it doesn't get too
much of a mess. We also use the GL renderer utility function
gl_find_unorm_format(), which saves us additional work with OpenGL's
semi-redundant format specifiers.
2017-01-16 16:10:39 +01:00
wm4
3a85976f8e cuda: fix AVHWFramesContext initialization
This was partially done. Strangely it worked anyway.
2017-01-16 16:10:39 +01:00
wm4
6b00663755 vo_opengl: hwdec_cuda: export AVHWDeviceContext
So we can use it for filtering later.
2017-01-16 16:10:39 +01:00
wm4
bbdecb792a hwdec: add a AVBufferRef(AVHWDeviceContext) field
This makes "generic" interaction with libav* components easier.
2017-01-16 16:10:22 +01:00
Olivier Perret
348c610b68 lua: allow unregistration of idle handlers 2017-01-15 17:02:21 +01:00
wm4
397705b12c manpage: define stricter rules for C plugin return values
Just in case.
2017-01-14 17:41:04 +01:00
wm4
e91331e683 scripting: don't call dlclose() on C plugins
Can break things quite badly.

Example: reloading a plugin linked against GTK 3.x can cause a segfault
if you call dlclose() on it. According to GTK developers, unloading the
GTK library is unsupported.
2017-01-14 17:14:30 +01:00
wm4
191cdbd31e scripting: minor logging improvements
Give scripting backends a proper name, instead of calling everything
"scripts".

Log client exit directly in client.c, as that is more general (doesn't
change actual output).
2017-01-14 17:13:50 +01:00
wm4
ddaab3349b vd_lavc: demote software decoding message to verbose log level
If hardware decoding is enabled (via --hwdec anything), the player was
printing an informational message that software decdoing is used.
Basically, this confuses users, because they think there is a problem or
such. Just disable the message, it's semi-useless anyway.

This was suggested on IRC, after yet another user was asking why this
message was shown (with a follow up discussion which CPUs can decode
what kind of video codecs).
2017-01-13 18:52:07 +01:00
wm4
e48f1f31cb vf_lavfi: remove pixel format whitelist
Pointless now.
2017-01-13 18:43:35 +01:00
wm4
6c28824a92 vo_opengl: hwdec_vaegl: add a lie for compatibility
EGL rendering + new decode API didn't work due to a certain libva bug
with sort-of legacy API use hitting again. It will report the wrong
vaapi pixel format. It's old code and always nv12 anyway, so stop
worrying about it.
2017-01-13 18:43:35 +01:00
wm4
812128bab7 vo_opengl, vaapi: properly probe 10 bit rendering support
There are going to be users who have a Mesa installation which do not
support 10 bit, but a GPU which can decode to 10 bit. So it's probably
better not to hardcode whether it is supported.

Introduce a more general way to signal supported formats from renderer
to decoder. Obviously this is imperfect, because it still isn't part of
proper format negotation (for example, what if there's a vavpp filter,
which accepts anything). Still slightly better than before.

I don't know any way to probe for vaapi dmabuf/EGL dmabuf support
properly (in particular testing specific formats, not just general
availability). So we stay with the current approach and try to create
and map dummy surfaces on init to probe for support. Overdo it and check
all formats that AVHWFramesConstraints reports, instead of only NV12 and
P010 surfaces.

Since we can support unknown formats now, add explicitly checks to the
EGL/dmabuf mapper code to reject unsupported formats. I also noticed
that libavutil signals support for RGB0/BGR0, but couldn't get it to
work. Remove the DRM formats that are unused/didn't work the way I tried
to use them.

With this, 10 bit decoding + rendering should work, provided you have
a capable CPU and a patched Mesa. The required Mesa patch adds support
for the R16 and GR32 formats. It was sent by a Kodi developer to the
Mesa developer mailing list and was not accepted yet.
2017-01-13 18:43:35 +01:00
wm4
d9376fc86f vaapi: always create AVHWDeviceContext on init
For convenience. Since we still have code that works even if creating a
AVHWDeviceContext fails, failure is ignored. (Although currently, it
succeeds creation even with the stale/abandoned vdpau wrapper driver.)
2017-01-13 13:35:31 +01:00
wm4
b26ab4d08c config: do not resolve default profile during "include" processing
Application of options in the default section is "delayed" until the
whole config file is read in order to allow profile forward references.
This was run at the end of parsing a config file - but because of
"include" options, this means it's not always called at the end of the
main config file.

Use the recursion counter to prevent it from being processed after each
"include" option. This also gets rid of the resulting unintended
infinite recursion (which eventually stopped and failed loading the
config file) due to m_config_finish_default_profile() processing the
"include" option again.

Fixes #4024.
2017-01-13 12:02:46 +01:00
wm4
88dfb9a5e7 vo_opengl: hwdec_vaegl: remove redundant vaapi surface format check
For surfaces allocated by libavutil, we assume that the sw_format (i.e.
in hw_subfmt in mp_image_params) is always correct. The API guarantees
that it explicitly sets the equivalent vaapi format on surface
allocation.

For surfaces allocated by mpv's old vaapi code, we explicitly retrieve
the format right after decoding. Unless the driver magically changes the
format asynchronously, it will still be correct once the surface reaches
the renderer.

In both cases, checking the format again is obviously redundant. In
addition, it doesn't require us to maintain a libva fourcc <-> mpfmt
table and the va_fourcc_to_imgfmt() function. This also unbreaks 10 bit
rendering support (still disabled by default).
2017-01-13 10:28:58 +01:00