| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
| |
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.)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead, use the native-endian alias, and switch the wayland format
depending on the target platform's endian.
This drops support for swapped-endian formats, but I think that is ok.
Not only are the affected formats rather ancient and backwards, but
using swapped formats probably does not make any sense for performance
either.
Untested.
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.)
|
|
|
|
|
| |
buffer_pool_get_front now returns always a valid buffer.
No need for corner cases.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. Separate buffer and temporary file handling from the vo to make maintenance
and reading code easier
2. Skip resizing as much as possible if back buffer is still busy.
3. Detach and mark osd buffers for deletion if we want to redraw them and they
are still busy. This could be a possible case for the video buffers as
well. Maybe better than double buffering.
All the above steps made it possible to have resizing without any artifacts
even for subtitles. Also fixes dozen of bugs only I knew, like broken subtitles
for rgb565 buffers. I can now sleep at night again.
|
| |
|
|
|
|
| |
This value is more accurate than the default value.
|
|
|
|
|
|
| |
I must have broken it some time ago. The error case dealing with an
unavailable backbuffer was broken, and didn't handle memory management
correctly.
|
|
|
|
|
|
|
|
| |
Follow up on commit 760548da. Mouse handling is a bit confusing, because
there are at least 3 coordinate systems associated with it, and it
should be cleaned up. But that is hard, so just apply a hack which gets
the currently-annoying issue (VO backends needing access to the VO) out
of the way.
|
|
|
|
|
|
| |
VO backends which are or will run in their own thread have a problem
with vo_mouse_movement() calling vo_control(). Restrict this to VOs
which actually need this.
|
|
|
|
|
|
| |
Do this simply by clearing the mapped buffer on every draw_image() call
without an actual video frame. (Maybe this is a bit expensive, but at
least not more expensive than regular video display.)
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Basically a cosmetic change. This is probably more intuitive.
|
|
|
|
|
|
|
|
|
| |
Let the VOs draw the OSD on their own, instead of making OSD drawing a
separate VO driver call. Further, let it be the VOs responsibility to
request subtitles with the correct PTS. We also basically allow the VO
to request OSD/subtitles at any time.
OSX changes untested.
|
|
|
|
|
|
|
| |
Subsurfaces are only used by the wayland vo. Thats why it makes sense to move
all osd and subsurface specific parts to the vo_wayland.c
Also destroy the subsurfaces and subcompositor properly.
|
|
|
|
|
|
|
|
|
|
|
| |
This affects packed RGB formats up to 16 bits per pixel. The old mplayer
names used LSB-to-MSB order, while FFmpeg (and some other libraries) use
MSB-to-LSB.
Nothing should change with this commit, i.e. no bit order or endian bugs
should be added or fixed. In some cases, the name stays the same, even
though the byte order changes, e.g. RGB8->BGR8 and BGR8->RGB8, and this
affects the user-visible names too; this might cause confusion.
|
|
|
|
|
|
| |
Additionally to removing the global variables, this makes the options
more uniform. --ssf-... becomes --sws-..., and --sws becomes --sws-
scaler. For --sws-scaler, use choices instead of magic integer values.
|
|
|
|
|
|
| |
It doesn't look like vo_wayland_config() necessarily sets this flag, so
it seems safer to trigger an explicit resize. This accounts for the case
when playing a new file with different size than the one before.
|
|
|
|
| |
Not very tested. Appears to work.
|
| |
|
|
|
|
| |
Rename it to reinit and check if parts of the pool are already allocated.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
I was unhappy with the old way of handling buffers, especially resizing. But my
original plan to use wl_shm_pool_resize wasn't as good as I initially thought.
I might get back to it.
With the new buffer pools it now possible to select triple buffering. Also the
buffer pools are also needed for the upcoming subsurfaces for osd and subtitles.
I hope this change was worth it.
|
|
|
|
| |
With the new xdg_shell the problem will be no gone by itself.
|
|
|
|
|
| |
Change minimum version to 1.3 and remove the version checking in the source
code.
|
|
|
|
| |
No real problem.
|
|
|
|
|
|
| |
RGB565 is one of the fastest and most supported formats on low end consumer
devices, but ffmpeg spams warning when using it. Make it opt-in instead of
opt-out.
|
| |
|
|
|
|
|
|
| |
The problem seems to have solved itself. I guess the previous changes to
resizing and commit ba101ab made this possible. Consider me happy for removing
that crap.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Do two things:
1. add locking to struct osd_state
2. make struct osd_state opaque
While 1. is somewhat simple, 2. is quite horrible. Lots of code accesses
lots of osd_state (and osd_object) members. To make sure everything is
accessed synchronously, I prefer making osd_state opaque, even if it
means adding pretty dumb accessors.
All of this is meant to allow running VO in their own threads.
Eventually, VOs will request OSD on their own, which means osd_state
will be accessed from foreign threads.
|
| |
|
|
|
|
| |
Those warnings are printed far too often and actually aren't usefull at all.
|
|
|
|
|
| |
There are still some leaks from wayland-cursor stuff, but there is no way to
free the memory as user of the cursor library.
|
|
|
|
|
|
|
| |
I added enough logic to never set ontop or fullscreen twitce.
This commit keeps also the size of the video if multiple videos are played.
If the ratio differs the width will be kept at the same size and only the
height changes.
|
|
|
|
|
| |
Only attach and commit new buffers. This also increases performance when
paused.
|
| |
|
|
|
|
|
| |
This was way too misleading. osd.c merely calls the subtitle renderers,
instead of actually dealing with subtitles.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The configure followed 5 different convetions of defines because the next guy
always wanted to introduce a new better way to uniform it[1]. For an
hypothetic feature 'hurr' you could have had:
* #define HAVE_HURR 1 / #undef HAVE_DURR
* #define HAVE_HURR / #undef HAVE_DURR
* #define CONFIG_HURR 1 / #undef CONFIG_DURR
* #define HAVE_HURR 1 / #define HAVE_DURR 0
* #define CONFIG_HURR 1 / #define CONFIG_DURR 0
All is now uniform and uses:
* #define HAVE_HURR 1
* #define HAVE_DURR 0
We like definining to 0 as opposed to `undef` bcause it can help spot typos
and is very helpful when doing big reorganizations in the code.
[1]: http://xkcd.com/927/ related
|
|
|
|
| |
The author and comment fields were printed only in -v mode.
|
|
|
|
|
|
| |
Problem: I own the buffer and I destroyed while still being displayed.
Solution: Add a temporary buffer and destroy it when the next buffer is
attached.
|
| |
|
|
|
|
| |
The previous method would break on the next release. Because I am stupid.
|
|
|
|
|
| |
For the time being there will be a check if someone uses wayland from git,
because I really really like to have the others formats too.
|
|
|
|
| |
Use a linked list for all supported formats and make the format table const.
|
| |
|
|
|
|
|
|
| |
Make use of opaque regions on non-alpha formats. This allows the compositor to
improve the drawing of the surface, because he can discard everything behind
the window when drawing.
|
|
A wayland output based on shared memory. This video output is useful for x11
free systems, because the current libGL in mesa provides GLX symbols. It is also
useful for embedded systems where the wayland backend for EGL is not
implemented like the raspberry pi.
At the moment only rgb formats are supported, because there is still no
compositor which supports planar formats like yuv420p. The most used compositor
at the moment, weston, supports only BGR0, BGRA and BGR16 (565).
The BGR16 format is the fastest to convert and render without any noticeable
differences to the BGR32 formats. For this reason the current (very basic)
auto-detection code will prefer the BGR16 format. Also the weston source code
indicates that the preferred format is BGR16 (RGB565).
There are 2 options:
* default-format (yes|no) Which uses the BGR32 format
* alpha (yes|no) For outputting images and videos with transparencies
|