summaryrefslogtreecommitdiffstats
path: root/video/out/gl_video.c
Commit message (Collapse)AuthorAgeFilesLines
* Fix some -Wshadow warningswm42013-07-231-5/+5
| | | | | | In general, this warning can hint to actual bugs. We don't enable it yet, because it would conflict with some unmerged code, and we should check with clang too (this commit was done by testing with gcc).
* vo_opengl: some option changeswm42013-07-221-1/+13
| | | | | | Doing "mpv --vo=opengl:lscale=help" now lists possible scalers and exits. The "backend" suboption behaves similar. Make the "stereo" suboption a choice, instead of using magic integer values.
* gl_video: add support for more rgb formatswm42013-07-181-40/+107
| | | | | | | | | | | | | | | 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-1/+1
|\ | | | | | | | | Conflicts: video/out/gl_video_shaders.glsl
| * Merge branch 'master' into low_quality_intel_crapwm42013-04-301-1/+1
| | | | | | | | | | | | Conflicts: video/out/gl_video_shaders.glsl video/out/vo_opengl.c
* | vo_opengl: handle chroma locationwm42013-06-281-0/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | video: add a new method to configure filters and VOswm42013-06-281-7/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The filter chain and the video ouputs have config() functions. They are strictly limited to transfering the video size and format. Other parameters (like color levels) have to be transferred separately. Improve upon this by introducing a separate set of reconfig() functions, which use mp_image_params to carry format parameters. This struct contains all image format related parameters from config(), plus additional parameters such as colorspace. Change vf_rotate to use it, as well as vo_opengl. vf_rotate is just an example/test case, but vo_opengl will need it later. The intention is also to get rid of VOCTRL_SET_YUV_COLORSPACE. This information is now handed to the VOs via reconfig(). The getter, VOCTRL_GET_YUV_COLORSPACE, will still be needed though.
* | gl_video: rearrange some codewm42013-06-151-23/+20
| | | | | | | | I think this is slightly nicer. Shouldn't change anything functionally.
* | gl_video: fix scaling when image is cropped, or with no-npotwm42013-06-151-22/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the displayed image is cropped in Y direction (like using panscan controls when playing 4:3 video on a 16:9 monitor), and separated scaling is used, the texture size for the FBO holding the intermediate result was calculated incorrectly. This could lead to artifacts, which were quite apparent with extreme scale factors. Actually, the size of that texture is OK, but the texture shouldn't be used to hold the complete scaled image. Instead, it should be used for the visible part of the image only. Because separate scaling works by scaling in Y direction first, it's still fine to scale the image on the full image width on the first pass. This helps avoiding artifacts on the left/right border of the image when scaling in X direction, as the scaler will try to fetch pixels from beyond the border. (The left border is still kind of fine, but the right border will fetch garbage, unless the texture is strictly sized, or explicit clamping is added to the shader. Too much trouble, so using the full image width is simpler.) Also fix some issues with no-npot mode, which enables use of power-of-2 textures. Maybe this mode isn't really useful anymore (modern hardware is faster with smaller non-power-of-2 textures), but keep it for now.
* | gl_video: typo in commentwm42013-06-151-1/+1
| |
* | gl_video: remove redundant conditionwm42013-06-131-6/+1
| |
* | gl_video: reduce output with -v, skip useless header partswm42013-06-031-5/+8
| | | | | | | | | | | | Originally, the header wasn't supposed to contain random compatibility stuff, but now all that is printed with -v. Add a hack to skip it and to reduce the noise.
* | gl_video: add some debug code for testing texture depthwm42013-05-301-7/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This probes and prints the depth of some texture formats with the help of a FBO. By default it tests the format used for scaling, as well as the format used for dithering and the 3D LUT (if any of these are enabled). The output is visible only with -v. Some representative values are probed, and the difference of input and output value is printed as hex- float. Hex-floats are used because they make the implied precision more obvious. Originally I wanted to do some more sophisticated guessing of the implied depth/precision for more user-friendly reporting, but then I decided that printing raw data is better for debugging, especially if things go wrong. This does not try to disable any functionality and does not print any warnings if the depth is lower than what it should be.
* | gl_video: fix some dithering bugswm42013-05-301-13/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-22/+77
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | gl_video: add scaler-resizes-only sub-optionwm42013-05-261-0/+24
| | | | | | | | | | This option disables the scaler set with lscale if the video image is not resized.
* | add a way to resize window contents without VO resizewm42013-05-121-7/+17
| | | | | | | | | | | | | | | | | | gl_video_resize_redraw() simply resizes and redraws (but without invoking swapGlBuffers()). The VO is not involved in any way, so this can simply be called from inside the mpgl lock from any thread. Requires a minor refactor of the GL OSD code in order to redraw without an OSD object.
* | vo_opengl: XYZ input supportwm42013-05-041-7/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: use GL_SRGB only if it's really RGBwm42013-05-041-2/+3
|/ | | | | Use the proper RGB flag instead of !YUV. Currently, this doesn't change anything, because only RGB and YUV formats are supported.
* gl_video: remove double const qualifierStefano Pigozzi2013-03-301-1/+1
| | | | This fixes a warning when compiling with clang.
* gl_video: add some missing includeswm42013-03-301-0/+8
| | | | On most platforms, they are recursively included, but not all.
* gl_video: actually fix shader compilation on OSXwm42013-03-281-2/+0
| | | | | | | | | | | | | 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.
* gl_video: fix OSX by not using undefined name in GLSL "#if"wm42013-03-281-0/+2
| | | | | | | | | | | | | | | | | | | The OSX shader compiler was giving this error: ERROR: 0:235: '' : syntax error incorrect preprocessor directive on this line: [235] #if USE_CONV == CONV_PLANAR USE_CONV was undefined in some cases. The expected behavior is that the shader preprocessor interprets this as branch not taken (AFAIK exactly as in C), which is probably what the standard would dictate. This is possible an OSX bug. But admittedly, I'm not sure whether this is really standard behavior (in C or GLSL), and doing this is extremely weird at best, so make sure that USE_CONV is always defined. Should fix behavior on OSX.
* gl_video: use choice option type for dither-depth suboptionwm42013-03-281-1/+2
| | | | | Replaces the numeric magic values -1 and 0 with "no" and "auto". The numeric values are still allowed for compatibility.
* gl_video: add some alpha FBO formatswm42013-03-281-1/+5
|
* vo_opengl: add alpha outputwm42013-03-281-1/+11
| | | | | | | | | | | | | | | | | | | 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: always upload all planeswm42013-03-281-15/+2
| | | | | | | When displaying YUV with alpha plane (an extremely rare special case), we didn't upload the alpha plane, because we don't do anything with it. This actually created some annoying special cases, so upload the alpha planes as well, even if they're unused.
* gl_video: support NV21 toowm42013-03-281-2/+3
|
* gl_video: add support for NV12wm42013-03-281-1/+13
| | | | | There's really no reason for this, but it feels nice being able to support a weird pixel format.
* gl_video: make it possible for planes to have different formatswm42013-03-281-38/+56
| | | | | | Preparation for NV12 support. Also adds support for IMGFMT_YA8.
* gl_video: move video image fields into a structwm42013-03-281-42/+68
| | | | | | This is a bit cleaner. Also don't repeat the chroma shift calculations over and over, but store the image size instead, which is simpler and will give us a chance to fix display of non-mod-2 image sizes.
* vo_opengl: split into multiple files, convert to new option APIwm42013-03-281-0/+1732
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-29 19:59:53 +0000