Commit Graph

88 Commits

Author SHA1 Message Date
wm4 14541ae258 Add checks for HAVE_GPL to various GPL-only source files
This should actually cover all of them, if you take into account that
some unchanged GPL source files include header files with such checks.
Also this was done already for the libaf derived code.

This is only for "safety" and to avoid misunderstandings.
2017-10-10 15:51:16 +02:00
wm4 1b2185657f vo_direct3d: fix build
Broken by previous commit. Fix completely untested.
2017-08-22 17:32:05 +02:00
wm4 03cf150ff3 video: redo video equalizer option handling
I really wouldn't care much about this, but some parts of the core code
are under HAVE_GPL, so there's some need to get rid of it. Simply turn
the video equalizer from its current fine-grained handling with vf/vo
fallbacks into global options. This makes updating them much simpler.

This removes any possibility of applying video equalizers in filters,
which affects vf_scale, and the previously removed vf_eq. Not a big
loss, since the preferred VOs have this builtin.

Remove video equalizer handling from vo_direct3d, vo_sdl, vo_vaapi, and
vo_xv. I'm not going to waste my time on these legacy VOs.

vo.eq_opts_cache exists _only_ to send a VOCTRL_SET_EQUALIZER, which
exists _only_ to trigger a redraw. This seems silly, but for now I feel
like this is less of a pain. The rest of the equalizer using code is
self-updating.

See commit 96b906a51d for how some video equalizer code was GPL only.
Some command line option names and ranges can probably be traced back to
a GPL only committer, but we don't consider these copyrightable.
2017-08-22 17:01:35 +02:00
wm4 2aff6f8c95 vo_direct3d: remove non-working nv12 shader support
It never worked. It relied on some obscure texture format to provide the
equivalent of GL_RG or GL_LUMINANCE_ALPHA, but no hardware seemed to
report support for it ever. No idea what's the correct way to do this.
On D3D11 it exists, of course.

(Actually I'd like to remove the whole VO.)
2017-06-30 18:13:01 +02:00
wm4 1ad036a2ef video: get rid of swapped packed YUV
Another legacy annoyance. The only place where packed YUV is still
important is slightly older Apple hardware or drivers, which require
it for efficient hardware decoding.
2017-06-30 18:01:29 +02:00
wm4 9b5281148c vo_direct3d: fix build
That format is worthless anyway.
2017-06-29 23:13:08 +02:00
wm4 af5a71f52e video: drop some unused IMGFMT aliases
These formats are supported in a generic way.

To get rid of IMGFMT_NV21, remove support from vo_direct3d.c completely.
2017-06-29 20:56:29 +02:00
wm4 1a2319f3e4 options: remove deprecated sub-option handling for --vo and --ao
Long planned. Leads to some sanity.

There still are some rather gross things. Especially g_groups is ugly,
and a hack that can hopefully be removed. (There is a plan for it, but
whether it's implemented depends on how much energy is left.)
2016-11-25 21:17:25 +01:00
James Ross-Gowan 803e2c5f87 win32: fix some Clang warnings
- win32-console-wrapper.c was inconsistently using the explicit Unicode
  versions of some Windows API functions and structures.
- vo.c should use llabs for int64_t, since long is 32-bit on Windows.
- vo_direct3d.c had a potential use of an uninitialized variable if it
  took the first goto error_exit.
2016-11-17 23:34:20 +11:00
wm4 7177ef3e1c vo: remove unused VOCTRL_GET_PANSCAN
It was used to determine whether the VO supports VOCTRL_SET_PANSCAN.
With all those changes to property semantics this became unnecessary,
and its only use was dropped at some point.
2016-09-08 18:59:21 +02:00
wm4 69283bc0f8 options: deprecate suboptions for the remaining AO/VOs 2016-09-05 21:26:39 +02:00
wm4 327cb2a06c vo_direct3d: deprecate direct3d_shaders alias
And remove the difference between the aliases. This is needed to make
the sub-option changes less painful.
2016-09-05 21:26:39 +02:00
Paul B Mahol d7a7e9a8c8 vo_direct3d: add missing header
Fixes build under cygwin.

Signed-off-by: wm4 <wm4@nowhere>
2016-08-14 21:51:59 +02:00
wm4 fd5098a409 vo_direct3d: remove bitmap packer
See previous comments.
2016-07-01 20:28:49 +02:00
stepshal c5094206ce Fix misspellings 2016-06-26 13:47:21 +02:00
wm4 ee4c00698f vo_direct3d: remove passing device to decoder
This was never really used anyway. Removing it for the sake of the
following commit.
2016-05-09 18:59:10 +02:00
wm4 3a015b9ec7 video: remove some useless old RGB formats
Some VOs had support for these - remove them.

Typically, these formats will have only some use in cases where using
RGB software conversion with libswscale is faster than letting the
VO/GPU do it (i.e. almost never). For the sake of testing this case,
keep IMGFMT_RGB565. This is the least messy format, because it has no
padding/alpha bits with unknown semantics.

Note that decoding to these formats still works. We'll let libswscale
repack the data to whatever the VO in use can take.
2016-01-25 10:43:35 +01:00
Dmitrij D. Czarkoff ea442fa047 mpv_talloc.h: rename from talloc.h
This change helps avoiding conflict with talloc.h from libtalloc.
2016-01-11 21:05:55 +01:00
wm4 45ae0716be csputils: rename "yuv2rgb" functions
They're not necessarily restricted to YUV aka YCbCr.

vo_direct3d.c and demux_disc.c (DVD specific code) changes untested.
2015-12-09 00:23:36 +01:00
wm4 b92fd602ce vo_direct3d: fix operation
Regression since commit 93db4233. I think the bit that was forgotten
here was to remove the vo_w32_config() return value completely. The VO
failed to init because that function always returned 0. This commit
removes these bits and fixes the VO.

Fixes #2434.
2015-10-31 12:52:02 +01:00
wm4 291f301c10 video/out: remove an unused parameter
This parameter has been unused for years (the last flag was removed in
commit d658b115). Get rid of it.

This affects the general VO API, as well as the vo_opengl backend API,
so it touches a lot of files.

The VOFLAGs are still used to control OpenGL context creation, so move
them to the OpenGL backend code.
2015-10-03 18:20:16 +02:00
wm4 93db4233af win32: cleanup: remove some unneeded things 2015-10-02 18:14:00 +02:00
wm4 c8fab7cc7b vo_direct3d: create multithreaded IDirect3DDevice9
A user complains that it leads to the dxva driver failing, leading to
messages like this:

[ffmpeg/video] h264: Failed to execute: 0x8007000e
[ffmpeg/video] h264: hardware accelerator failed to decode picture

Reportedly, this happens only with vo_direct3d, not with vo_opengl. The
only difference is that vo_direct3d attempts to share the D3D device
with the decoder. Possibly the error is that the device in the VO is not
created with D3DCREATE_MULTITHREADED. Change this.

Probably fixes #2178.
2015-07-30 21:26:42 +02:00
wm4 b85321d057 vo_direct3d, dxva2: use the same D3D device
Since we still read-back (and don't have hard plans on changing this),
this doesn't have much of an advantage.
2015-07-03 16:04:42 +02:00
wm4 af667643a0 video: do not align source position to 2
vo_direct3d still seems to require this (tested on Windows 8.1 with
Intel graphics). Do it in vo_direct3d instead of messing with all VOs.
2015-05-21 19:27:54 +02:00
Marcin Kurczewski f43017bfe9 Update license headers
Signed-off-by: wm4 <wm4@nowhere>
2015-04-13 12:10:01 +02:00
wm4 f6b2325c2a video/out: fix screenshot image formats
Use variants without alpha.

I skipped vo_sdl, because format selection seems a bit more complicated
here, and nobody cares about vo_sdl anymore.
2015-04-07 11:43:03 +02:00
wm4 8f0f73e591 video/out: remove unused colorspace reporting
Rarely used and essentially useless. The only VO for which this was
implemented correctly and for which this did anything was vo_xv, but you
shouldn't use vo_xv anyway (plus it support BT.601 only, plus a vendor
specific extension for BT.709, whose presence this function essentially
reported - use xvinfo instead).
2015-03-31 00:09:03 +02:00
wm4 5f2a8474ae video: uninline memcpy_pic functions
There's literally no reason why these functions have to be inline (they
might be performance critical, but then the function call overhead isn't
going to matter at all).

Uninline them and move them to mp_image.c. Drop the header file and fix
all uses of it.
2015-03-20 00:21:23 +01:00
wm4 51befc9deb osd: simplify an aspect of change detection handling
There was a somewhat obscure optimization in the OSD and subtitle
rendering path: if only the position of the sub-images changed, and not
the actual image data, uploading of the image data could be skipped. In
theory, this could speed up things like scrolling subtitles.

But it turns out that even in the rare cases subtitles have such scrolls
or axis-aligned movement, modern libass rarely signals this kind of
change. Possibly this is because of sub-pixel handling and such, which
break this.

As such, it's a worthless optimization and just introduces additional
complexity and subtle bugs (especially in cases libass does the
opposite: incorrectly signaling a position change only, which happened
before). Remove this optimization, and rename bitmap_pos_id to
change_id.
2015-03-18 13:15:20 +01:00
wm4 85bf102f54 win32: fix some more -Wparentheses warnings
Stupid compiler.

For decode_surrogate_pair(), I changed the order of evaluation; it
shouldn't matter, but this order is more readable in my opinion.
2015-03-04 17:28:41 +01:00
wm4 4b177bd5c2 vo_direct3d: support NV12 with shaders
Semi-important, because --hwdec=dxva2 outputs NV12, and we really don't
want people to end up with the "old" StretchRect method.

Unfortunately, I couldn't actually get it to work. It seems most D3D
drivers (including the wine D3D implementation) reject D3DFMT_A8L8,
and I could not find any other 2-channel 8 bit Direct3D 9 format. It
seems newer D3D APIs have DXGI_FORMAT_R8G8_UNORM, but there's no way
to get it in D3D9.

Still pushing this; maybe it actually works on some drivers.
2015-03-02 19:09:18 +01:00
wm4 2858232220 vo: simplify VOs by adding generic screenshot support
At the time screenshot support was added, images weren't refcounted yet,
so screenshots required specialized implementations in the VOs. But now
we can handle these things much simpler. Also see commit 5bb24980.

If there are VOs in the future which can't do this (e.g. they need to
write to the image passed to vo_driver->draw_image), this still could be
disabled on a per-VO basis etc., so we lose no potential performance
advantages.
2015-01-24 23:16:27 +01:00
wm4 5e9f791667 video: separate screenshot modes
Use different VOCTRLs for "window" and normal screenshot modes. The
normal one will probably be removed, and replaced by generic code in
vo.c, and this commit is preparation for this. (Doing it the other way
around would be slightly simpler, but I haven't decided yet about the
second one, and touching every VO is needed anyway in order to remove
the unneeded crap. E.g. has_osd has been unused for a long time.)
2015-01-23 22:08:20 +01:00
wm4 a1ed13869c video: remove vfcap.h
And remove all uses of the VFCAP_CSP_SUPPORTED* constants. This is
supposed to reduce conversions if many filters are used (with many
incompatible pixel formats), and also for preferring the VO's natively
supported pixel formats (as opposed to conversion).

This is worthless by now. Not only do the main VOs not use software
conversion, but also the way vf_lavfi and libavfilter work mostly break
the way the old MPlayer mechanism worked. Other important filters like
vf_vapoursynth do not support "proper" format negotation either.

Part of this was already removed with the vf_scale cleanup from today.

While I'm touching every single VO, also fix the query_format argument
(it's not a FourCC anymore).
2015-01-21 22:08:24 +01:00
wm4 3f49c60762 vo_direct3d: unify d3d "reset" and uninit paths
I'm still not sure how exactly handling of "lost" devices is supposed
to be handled. In theory, you only have to "reset" the device, instead
of recreating _everything_. But as it is, the code for proper uninit
and for handling the reset is exactly the same, so move it into a
function to reduce code duplication and the danger of potential bugs.
2015-01-21 21:12:18 +01:00
wm4 39231e5dfd vo_direct3d: disable shaders if unavailable
Apparently, extremely crappy graphics drivers don't allow you to use
shaders. Simply disable use of shaders if this happens, and use the
"old" method instead.

One unexpectedly tricky thing is that you need a d3d_device to create
a shader, which in turn requires a window, so the initialization order
changes.
2015-01-21 21:06:56 +01:00
wm4 02dbd41ae0 vo_direct3d: fix shader colormatrix generation
It was accidentally broken in d42d60bc1.
2015-01-07 22:08:20 +01:00
wm4 5410a5b2c5 csputils: move image_params -> csp_params into a function
Although the line count increases, this is better for making sure
everything is handled consistently for all users of the mp_csp_params
stuff.

This also makes sure mp_csp_params is always initialized with
MP_CSP_PARAMS_DEFAULTS (for consistency).
2015-01-06 16:51:02 +01:00
wm4 a52ca8a2b0 csputils: get rid of mp_csp_details
It used to be central, but now it's just unneeded.
2015-01-06 16:50:58 +01:00
wm4 5db162231e vo_direct3d: check whether D3DFMT_A8 is available
I suspect this is what is happening in github issue #1265 (at least
partially).

If D3DFMT_A8 is not available, fall back to RGBA. This is less efficient
in general, so we normally want to avoid it.
2014-11-27 20:05:29 +01:00
wm4 b8ac594af0 vo_direct3d: fix texture-memory sub-option, extend it
This sub-option was turned into a flag when the sub-option parser was
changed to the generic one (probably accidentally). Turn it into a
proper choice-option.

Also, adjust what the options do. Though none of this probably makes
much sense; the default should work, and if it doesn't, the GPU/driver
is probably beyond help.
2014-11-18 16:30:32 +01:00
wm4 4e2574f025 command: make window-scale property observable
Add a generic mechanism to the VO to relay "extra" events from VO to
player. Use it to notify the core of window resizes, which in turn will
be used to mark all affected properties ("window-scale" in this case) as
changed.

(I refrained from hacking this as internal command into input_ctx, or to
poll the state change, etc. - but in the end, maybe it would be best to
actually pass the client API context directly to the places where events
can happen.)
2014-11-02 20:53:56 +01:00
wm4 3b34f0078d vo_direct3d: support nv12/nv21 directly 2014-10-26 02:36:15 +02:00
wm4 19fd67096b vo_direct3d: allow resizing before video init
This can just happen in the time between VO creation, and the first call
to vo_reconfig. It seems the recent threading changes exposed this bug.

Fixes #986.
2014-08-06 20:30:47 +02:00
wm4 77ad49411a win32: never call GetClientRect(0, ...)
Sometimes GetClientRect() appeared to fail during init, and since we
don't check GetClientRect() calls (because they're on our own window,
and logically can never fail), bogus resizes were triggered. This could
cause vo_direct3d to fail initialization.

The reason was that w32->window was set to 0 during early window
initialization: CreateWindow*() can send messages to the new window,
even though it hasn't returned yet. This means w32->window is not yet
set to our window handle, and functions in WndProc may accidentally pass
hwnd=0 to win32 API functions.

Fix it by initializing w32->window on opportunity. This also means we
always strictly expect that the WndProc is used with our own window
only.
2014-08-06 20:30:47 +02:00
wm4 b3169390f5 win32: make private struct private, refactor
Preparation for moving win32 windowing to a separate thread.

The codesize is reduced a bit, because some small functions are
inlined, which reduces noise.

The main change is that now most functions use the private struct
directly, instead of accessing it indirectly through vo->w32.
Accesses to vo are minimalized.

The final goal is adding some sort of new windowing backend API. It
would be cleaner to use that as context pointer for all functions
(like struct vo was previously used), but since this is work in
progress, we just go with this commit.
2014-07-26 20:27:03 +02:00
wm4 9accfe0426 video/out: fix redrawing with no video frame for some VOs
With the change to merge osd drawing into video frame drawing, some
bogus logic got in: they skipped drawing the OSD if no video frame is
available. This broke --no-video --force-window mode.
2014-06-18 20:04:59 +02:00
wm4 90cd5aa8c8 vo: make draw_image and vo_queue_image transfer image ownership
Basically a cosmetic change. This is probably more intuitive.
2014-06-17 23:05:50 +02:00
wm4 72aac9ae8a video: introduce failure path for image allocations
Until now, failure to allocate image data resulted in a crash (i.e.
abort() was called). This was intentional, because it's pretty silly to
degrade playback, and in almost all situations, the OOM will probably
kill you anyway. (And then there's the standard Linux overcommit
behavior, which also will kill you at some point.)

But I changed my opinion, so here we go. This change does not affect
_all_ memory allocations, just image data. Now in most failure cases,
the output will just be skipped. For video filters, this coincidentally
means that failure is treated as EOF (because the playback core assumes
EOF if nothing comes out of the video filter chain). In other
situations, output might be in some way degraded, like skipping frames,
not scaling OSD, and such.

Functions whose return values changed semantics:

  mp_image_alloc
  mp_image_new_copy
  mp_image_new_ref
  mp_image_make_writeable
  mp_image_setrefp
  mp_image_to_av_frame_and_unref
  mp_image_from_av_frame
  mp_image_new_external_ref
  mp_image_new_custom_ref
  mp_image_pool_make_writeable
  mp_image_pool_get
  mp_image_pool_new_copy
  mp_vdpau_mixed_frame_create
  vf_alloc_out_image
  vf_make_out_image_writeable
  glGetWindowScreenshot
2014-06-17 22:43:43 +02:00