| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
| |
Since e207c24b32a457859ab6e3a5b1f5f9eaeea36ed1, vf_mirror requires
libavfilter.
Signed-off-by: wm4 <wm4@nowhere>
|
| |
|
|
|
|
| |
This prevents the machine from going to sleep while a video-only stream
is playing. When audio is playing, the audio stack should make this
request for us.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Logging was meant to be silenced only when user uses connector
auto-detection feature. If user supplies connector ID manually, he
should see exact reason why connecting to this specific connector
failed.
|
| |
|
|
| |
Fixes #1828
|
| |
|
|
| |
Fixes #1827
|
| |
|
|
| |
These are redundant.
|
| |
|
|
|
| |
Currently, libavfilter's equivalent vf_hflip is probably not faster or
anything, but there's still no reason to keep the internal code.
|
| |
|
|
|
| |
I assume this was intended to generate an initial change event in order
to make the user read the initial values.
|
| |
|
|
|
| |
And also undoxygenify a comment. (There used to be some inconsistent
doxygen comments in MPlayer time; they are being removed on sight.)
|
| |
|
|
|
|
| |
It's entirely useless, especially now that vo.c handles screenshots in a
generic way, and requires no special VO support. There are some
potential weird use-cases, but actually I've never seen it being used.
|
| |
|
|
| |
Signed-off-by: wm4 <wm4@nowhere>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We already use 2 screensaver APIs when attempting to disable the
screensaver: XResetScreenSaver() (from xlib) and XScreenSaverSuspend
(from the X11 Screen Saver extension). None of these actually work.
On modern desktop Linux, we are expected to make dbus calls using some
freedesktop-defined protocol (and possibly we'd have to fallback to a
Gnome specific one). At least xscreensaver doesn't respect the "old"
APIs either.
Solve this by running the xdg-screensaver script. It's a terrible, ugly
piece of shit (just read the script if you disagree), but at least it
appears to work everywhere. It's also simpler than involving various
dbus client libraries.
I hope this can replace the --heartbeat-cmd option, and maybe we could
remove our own DPMS/XSS code too.
|
| |
|
|
|
| |
Use a choice instead of an integer. This is incompatible, but I'm not
adding any compatibility since this option was added recently.
|
| |
|
|
|
|
|
| |
This is optional, but ensures that linking with -Wl,--as-needed does
not drop the MMAL VC driver. The driver normally "registers" itself
in the library constructor, but since no symbols are explicitly
referenced, the linker could remove it with as-needed enabled.
|
| |
|
|
| |
Signed-off-by: wm4 <wm4@nowhere>
|
| |
|
|
|
|
|
|
|
|
| |
Not sure why this was so roundabout; probably to keep spam down if the
user's OpenGL drivers are crap (but then just don't enable extended
features), or because the "Disabling..." text was so repetitious.
But there doesn't seem to be a good reason after all. Also, this could
already overflow the fixed size disabled[] array. Just print the
messages directly.
|
| | |
|
| |
|
|
|
| |
Since scaling the video changes the aspect ratio, we have to compensate
for this when rendering subtitles.
|
| |
|
|
|
| |
This can be used to draw the subtitles at the video's native res, which
can make them look more natural and increases performance.
|
| |
|
|
|
|
|
| |
Because gcc (and clang) is a goddamn PITA and unnecessarily warns if
the universal initializer for structs is used (like mp_image x = {})
and the first member of the struct is also a struct, move the w/h
fields to the top.
|
| | |
|
| |
|
|
| |
Seems relatively painful in this case, but they are morally wrong.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
They are redundant. They were used by draw_bmp.c only, and only in a
special code path that 1. used fixed image formats, and 2. had image
sized perfectly aligned to chroma boundaries (so computing the chroma
width/height is trivial).
|
| | |
|
| |
|
|
|
| |
A screenshot from a 4:2:0 video will use 4:2:0, RGB will use 4:4:4, and
so on. (The image data still goes through RGB conversion always.)
|
| |
|
|
|
|
|
| |
This could help in cases where the DWM (Windows desktop compositor) adds another
layer of bufferring and therefore the SwapBuffers timing could get messed up.
Signed-off-by: wm4 <wm4@nowhere>
|
| |
|
|
|
|
|
|
| |
on my windows system this allows smoothmotion to work perfectly also in windowed
mode. There's no real right or wrong here, with the the only goal being to
always hit the next vsync. however, on cases where vsync timing is jittery (as
could happen with DWM), this patch tries to aim to the middle of the vsync cycle
to get as least affected as possible by such jitter.
|
| |
|
|
|
|
|
|
| |
adds 1 vsync interval "slack" before deciding to drop the first frame. it should
help on cases of timing jitter (sleep duration, container timestamps, compositor
vsync timing, etc). once the drop threshold has been crossed, it will keep
dropping until perfect timing alignment. this prevents crossing the drop
threshold back and forth repeatedly and therefore more resilient to frame drops
|
| |
|
|
| |
Its vp parameter made no sense anymore. Introduce a new one.
|
| |
|
|
|
|
|
| |
And also let vo.c know of it.
Currently, this does not help much, but will facilitate future
improvements.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Increase the default queue size. This helps with "missed" frames due to
the asynchronous nature of the API. All the other VOs are synchronous,
so if rendering and displaying takes a while, the common code in vo.c
will be blocked until it can continue. But with opengl-cb, vo.c might
immediately push the next ready frame, which causes the current frame
to be dropped _if_ it wasn't rendered yet.
One could fix this by making vo.c wait a while (until the API user calls
the render function, which pulls the frame). But setting the default
queue size to 2 seems much simpler: instead of dropping the frame, it
will be pushed to the API user once the next renderer call finishes.
(This is still a bit strange, and will hopefully be cleaned up when
video scheduling is redone, but for now this appears to deliver
relatively good results.)
|
| |
|
|
|
| |
Now don't ask me why the GLXFBConfig type is a pointer, but stores an
integer ID.
|
| | |
|
| |
|
|
|
|
|
| |
Use variants without alpha.
I skipped vo_sdl, because format selection seems a bit more complicated
here, and nobody cares about vo_sdl anymore.
|
| |
|
|
| |
Fixes #1779.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This matters for png screenshots. We used to hardcode rgb24, but
libavformat's png encoder can do much more. Use the image format list
provided by the encoder, and select the best format from it (according
to the source format).
As a consequence, rgb48 (i.e. 16 bit per component) will be selected if
the source format is e.g. 10 bit yuv. This happens in accordance to
FFmpeg's avcodec_find_best_pix_fmt_of_list() function, which assumes
that 16 bit rgb should be preferred for 10 bit yuv.
This also causes it to print this message in this case:
[ffmpeg] swscaler: full chroma interpolation for destination format 'rgb48be' not yet implemented
I'm not 100% sure whether this is a problem.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use texture-from-pixmap instead of vaapi's "native" GLX support.
Apparently the latter is unused by other projects. Possibly it's broken
due that, and Intel's inability to provide anything non-broken in
relation to video.
The new code basically uses the X11 output method on a in-memory pixmap,
and maps this pixmap as texture using standard GLX mechanisms. This
requires a lot of X11 and GLX boilerplate, so the code grows. (I don't
know why libva's GLX interop doesn't just do the same under the hood,
instead of bothering the world with their broken/unmaintained "old"
method, whatever it did. I suspect that Intel programmers are just
genuine sadists.)
This change was suggested in issue #1765.
The old GLX support is removed, as it's redundant and broken anyway.
One remaining issue is that the first vaPutSurface() call fails with an
unknown error. It returns -1, which is pretty strange, because vaapi
error codes are normally positive. It happened with the old GLX code
too, but does not happen with vo_vaapi. I couldn't find out why.
|
| | |
|
| | |
|
| |
|
|
|
| |
With target-prim and target-trc it makes sense to include some common
colorspaces that aren't strictly speaking used for video.
|
| | |
|
| | |
|
| |
|
|
| |
No real reason this is disabled with the new configuration API.
|
| |
|
|
| |
This lets us tune the window parameter
|
| |
|
|
|
|
|
| |
This is a peculiar filter I stumbled upon while playing around with
windows, it removes aliasing almost completely while not ringing at all.
The downside is that it's quite blurry, but at high resolutions it's not
so noticeable.
|
| |
|
|
| |
Will have to find a source before re-adding.
|
xylosper
James Ross-Gowan
Marcin Kurczewski
wm4
Niklas Haas
Avi Halachmi (:avih)