| Age | Commit message (Collapse) | Author |
|---|
|
video_out_vaapi.c: In function âvaapi_ovl_associateâ:
video_out_vaapi.c:2465:5: warning: passing argument 3 of âvaMapBufferâ from incompatible pointer type
/usr/local/include/va/va.h:1830:10: note: expected âvoid **â but argument is of type âunsigned char **â
No joke.
|
|
User fragment shaders are probably unaffected anyway,
but the 1:1 case may get a bit faster.
|
|
Patch from https://bugs.freedesktop.org/show_bug.cgi?id=77408
|
|
That 0.5 thing is OK as all texture coordinates refer to the middle of a pixel.
However, we dont need abs() as the diff already is 0.0 <= diff < 1.0 .
|
|
|
|
catmullrom_spline (-2, -1, 0, 1, 2) == (0, 0, 1, 0, 0)
so when width and/or height stays the same it may be skipped.
In the best possible case, there will be some GPU power saving.
|
|
Also, guard against requesting/setting unsupported properties.
And fix video eq handling like in vo_xv.
This is based on my earlier vo_xv and vo_vdpau extensions,
and some unused part of vo_vaapi itself.
The ffmpeg vaapi wrapper seems to ignore va_context.colorspace.
If that information is at all present, it will be in AVContext
and vo_frame.flags as usual, so there might be a chance for this to
work.
Finally, I have a (minor build fixed) VAAPI emulator on top of
VDPAU for testing :-)
|
|
|
|
Fixes fb video out with recent Ubuntu.
|
|
|
|
|
|
Enables use of SDL video output with fbxine.
Under X11 fbxine + SDL draws to X11 window.
|
|
|
|
run-time deps.
SDL video output works perfectly well under X11 even if xine-lib was built without X11 support.
|
|
|
|
|
|
|
|
This should fix wrong colors in large still images there, for example.
BTW. I stumbled upon that manpage while looking for something else :-/
|
|
|
|
|
|
The same code is not always warned about (vo_fb was, xshm was not).
The gcc manpage says type punning is allowed via unions only,
but this would mean either breaking the API, or using slow
workarounds. Anyway, this here seems to be the least invasive way.
|
|
Also, do a proper blackfill to avoid green edges.
|
|
Also, blackfill the whole frame (not just the bottom),
as the libyuv2rgb line scaler may read over the right border,
and we dont know where it will be here due to cropping.
|
|
|
|
Also, do proper blackfill to avoid dark green edges.
|
|
Also, do proper blackfill to avoid dark green edges.
|
|
|
|
Making them all "const char * const *" did work too
(even with Kaffeine build/run), but that would be
an API change.
|
|
Possibly only theory. Most real life YCgCo files are 4:4:4 what VDPAU dislikes.
|
|
|
|
I stumbled upon something - the green orange transform :-)
No, it is not lossless as some publications say. Instead, like traditional
YCbCr it maps the RGB color cube to a pyramid with a central symmetric
hexagonal base. Roughly 80% of color depth gets lost this way. The green
resolution is again worse than ITU-R 709.
It will probably not replace traditional YCbCr. It is incompatible with
existing video equipment, and it lacks an mpeg range mode needed for live editing.
However, if you can live without video equalizer, it makes an interesting
alternative for slow devices like smartphones.
Anyway, just if someone likes...
|
|
|
|
|
|
|
|
This is preferred on any half-way sRGB compliant monitors.
|
|
This bug probably never hit anyway. Nobody uses 24bpp X displays,
as they are way slower than 32 bit ones, or even unsupported by hw.
|
|
|
|
|
|
|
|
The real bug was libyuv2rgb_mmx outputting bgr24 instead of
requested rgb24. Previous fix tried to work around by swapping
the input UV planes as well. Better than nothing but... well.
Now both modes are supported, and kludge removed.
|
|
Still not sure whether this is the end of the story now.
|
|
|
|
|
|
script execution time: 55"
|
|
|
|
Tested by provoking a Kaffeine segfault.
|
|
|
|
|
|
|
|
|
