summaryrefslogtreecommitdiffstats
path: root/video/out/gl_video_shaders.glsl
Commit message (Collapse)AuthorAgeFilesLines
* vo_opengl: blend alpha components by defaultwm42013-09-191-0/+3
| | | | | | Improves display of images and video with alpha channel, especially if the transparent regions contain (supposed to be invisible) garbage color values.
* gl_video: add support for more rgb formatswm42013-07-181-16/+12
| | | | | | | | | | | | | | | Until now, only formats directly supported by OpenGL were supported. This excludes various permutations of 8-bit RGB[A|0]. But we can simply permutate the color channels in the shader, so do that. This also adds support for all these weird RGB0 formats. Note that we could use libavutil's pixfmt list instead of the mp_packed_formats array, but trying to decrypt the pixfmt info would probably end in pain, so this array with duplicated information is actually better and shorter. Note: I didn't actually test whether the alpha components are reproduced correctly with alpha formats.
* Merge remote-tracking branch 'origin/low_quality_intel_crap'Martin Herkt2013-07-081-13/+16
|\ | | | | | | | | Conflicts: video/out/gl_video_shaders.glsl
| * Merge branch 'master' into low_quality_intel_crapwm42013-04-301-13/+16
| | | | | | | | | | | | Conflicts: video/out/gl_video_shaders.glsl video/out/vo_opengl.c
* | vo_opengl: handle chroma locationwm42013-06-281-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use the video decoder chroma location flags and render chroma locations other than centered. Until now, we've always used the intuitive and obvious centered chroma location, but H.264 uses something else. FFmpeg provides a small overview in libavcodec/avcodec.h: ----------- /** * X X 3 4 X X are luma samples, * 1 2 1-6 are possible chroma positions * X X 5 6 X 0 is undefined/unknown position */ enum AVChromaLocation{ AVCHROMA_LOC_UNSPECIFIED = 0, AVCHROMA_LOC_LEFT = 1, ///< mpeg2/4, h264 default AVCHROMA_LOC_CENTER = 2, ///< mpeg1, jpeg, h263 AVCHROMA_LOC_TOPLEFT = 3, ///< DV AVCHROMA_LOC_TOP = 4, AVCHROMA_LOC_BOTTOMLEFT = 5, AVCHROMA_LOC_BOTTOM = 6, AVCHROMA_LOC_NB , ///< Not part of ABI }; ----------- The visual difference is literally minimal, but since videophiles apparently consider this detail as quality mark of a video renderer, support it anyway. We don't bother with chroma locations other than centered and left, though. Not sure about correctness, but it's probably ok.
* | gl_video: explicitly clamp colormatrix outputwm42013-06-031-0/+1
| | | | | | | | | | | | | | This could lead to quite visible artifacts when using an appropriate ICC and float FBOs. The float FBOs allow storing out of range values, and my guess is that the rest of the precessing chain elevated these out of range values, resulting in artifacts.
* | gl_video: change a GLSL statementwm42013-05-301-1/+1
| | | | | | | | | | | | This might be better with dumb shader compilers, which won't vectorize this to a single vector-division, assuming the hardware does have such an instruction. Affects "bicubic_fast" scale mode only.
* | gl_video: fix some dithering bugswm42013-05-301-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The internal texture format GL_RED is typically 8 bit, which is clearly not good enough for the new dither matrix. The idea was to use a float texture format, but this was somehow "forgotten". Use GL_R16, since 16 bit textures are more robust, and provide more precision for the same memory usage. Change how the offset for centering the dither matrix is applied. This is needed for making it possible to round up values to the target depth. Before this commit, this changed the output even if the input was exact and input and output depth were the same, which is not really what you want. Now it doesn't do that anymore.
* | gl_video: improve ditheringwm42013-05-261-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use a different algorithm to generate the dithering matrix. This looks much better than the previous ordered dither matrix with its cross-hatch artifacts. The matrix generation algorithm as well as its implementation was contributed by Wessel Dankers aka Fruit. The code in dither.c is his implementation, reformatted and with static global variables removed by me. The new matrix is uploaded as float texture - before this commit, it was a normal integer fixed point matrix. This means dithering will be disabled on systems without float textures. The size of the dithering matrix can be configured, as the matrix is generated at runtime. The generation of the matrix can take rather long, and is already unacceptable with size 8. The default is at 6, which takes about 100 ms on a Core2 Duo system with dither.c compiled at -O2, which I consider just about acceptable. The old ordered dithering is still available and can be selected by putting the dither=ordered sub-option. The ordered dither matrix generation code was moved to dither.c. This function was originally written by Uoti Urpala.
* | vo_opengl: XYZ input supportwm42013-05-041-2/+6
|/ | | | | | | | | | | | | | | | Useful for the j2k decoder. Matrix taken from http://www.brucelindbloom.com/index.html?Eqn_RGB_XYZ_Matrix.html (XYZ to sRGB, whitepoint D65) Gamma conversion follows what libswscale does (2.6 in, 2.2 out). If linear RGB is used internally for scaling, the gamma conversion will be undone by setting the exponent to 1. Unfortunately, the two gamma values don't compensate each others exactly (2.2 vs. 1/0.45=2.22...), so output is a little bit incorrect in sRGB or color-managed mode. But for now try hard to match libswscale output, which may or may not be correct.
* gl_video: actually fix shader compilation on OSXwm42013-03-281-0/+3
| | | | | | | | | | | | | The previous attempt was missing some code paths, so there were still shaders generated that triggered the shader compilation error. Fix it instead by special handling USE_CONV in the shader. By the way, the shader compiler did not accept: #if defined(USE_CONV) && (USE_CONV == ...) In my opinion this should be perfectly fine, but it gives the same error as before. So test USE_CONV separately with #ifndef.
* vo_opengl: add alpha outputwm42013-03-281-4/+16
| | | | | | | | | | | | | | | | | | | Allows playing video with alpha information on X11, as long as the video contains alpha and the window manager does compositing. See vo.rst. Whether a window can be transparent is decided by the choice of the X Visual used for window creation. Unfortunately, there's no direct way to request such a Visual through the GLX or the X API, and use of the XRender extension is required to find out whether a Visual implies a framebuffer with alpha used by XRender (see for example [1]). Instead of depending on the XRender wrapper library (which would require annoying configure checks, even though XRender is virtually always supported), use a simple heuristics to find out whether a Visual has alpha. Since getting it wrong just means an optional feature will not work as expected, we consider this ok. [1] http://stackoverflow.com/questions/4052940/how-to-make-an-opengl- rendering-context-with-transparent-background/9215724#9215724
* gl_video: support NV21 toowm42013-03-281-0/+3
|
* gl_video: add support for NV12wm42013-03-281-1/+7
| | | | | There's really no reason for this, but it feels nice being able to support a weird pixel format.
* vo_opengl: split into multiple files, convert to new option APIwm42013-03-281-0/+359
gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-03 22:12:33 +0000