summaryrefslogtreecommitdiffstats
path: root/video/out/gl_video.c
Commit message (Collapse)AuthorAgeFilesLines
* m_option: add mp_log callback to OPT_STRING_VALIDATE optionswm42013-12-211-7/+7
| | | | | And also convert a bunch of other code, especially ao_wasapi and ao_portaudio.
* Split mpvcore/ into common/, misc/, bstr/wm42013-12-171-1/+1
|
* gl_video: change internal API for hwdec mp_image downloadStefano Pigozzi2013-12-021-1/+2
| | | | | | Previous API worked under the assumption that download_image is always called after map_image. In practice this is true, but it's better to have a much generic API that doesn't depend on the order in which the functions are called.
* gl_video: use hwdec download_image call only if hwdec is activewm42013-12-021-2/+3
| | | | | | | | | | The hwdec driver can be loaded, even if it's not used (e.g. when playing a file with no hardware decoding after one with it enabled). Also, check whether dlimage is NULL. Since this will do call into the native hwdec API, there's a chance a driver could fail doing this, it's better to check the return value, even if this case currently can't happen.
* vo_opengl: support for vda hardware decodingStefano Pigozzi2013-12-021-0/+6
| | | | | | | | | | | The harder work was done in the previous commits. After that this feature comes out almost for free. The only problem is I can't get the textures created with CGLTexImageIOSurface2D to download properly, thus the code performs download using some CoreVideo APIs. If someone knows why download of textures created with CGLTexImageIOSurface2D doesn't work please contact me :)
* gl_video: support packed YUV formats with Apple extensionsStefano Pigozzi2013-12-021-2/+23
| | | | | | | | | | This adds support for packed YUV formats (YUVY and UYVY) using the extension GL_APPLE_rgb_422. While supporting this formats on their own is not that important (considering most video is planar YUV) they are used for interoperability with IOSurfaces. Next commit will use this formats to render VDA hardware decoded frames through IOSurface and OpenGL interoperability.
* vo_opengl: add support for rectangle textureswm42013-12-011-31/+60
| | | | | | | | | This allows vo_opengl to use GL_TEXTURE_RECTANGLE textures, either by enabling it with the 'rectangle-textures' sub-option, or by having a hwdec backend force it. By default it's off. The _only_ reason we're adding this is because VDA can export rectangle textures only.
* gl_hwdec: use a imgfmt field instead of a query_format callbackwm42013-11-291-1/+1
| | | | | Now that vdpau always uses a single image format, this can be simplified.
* vo_opengl: redo aspects of initialization, change hwdec APIwm42013-11-051-24/+24
| | | | | | | | | | | Instead of checking for resolution and image format changes, always fully reinit on any parameter change. Let init_video do all required initializations, which simplifies things a little bit. Change the gl_video/hardware decoding interop API slightly, so that hwdec initialization gets the full image parameters. Also make some cosmetic changes.
* vo_opengl: cosmetics/fix typoswm42013-11-041-1/+1
|
* vo_opengl: reserve 4 texture units for video instead of 3wm42013-11-041-5/+5
| | | | | | | | | | Video has up to 4 textures, if you include obscure formats with alpha. This means alpha formats could always overwrite the first scaler texture, leading to corrupted video display. This problem was recently brought to light, when commit 571e697 started to explicitly unbind all 4 video textures, which broke rendering for non-alpha formats as well. Fix this by reserving the correct number of texture units.
* Merge remote-tracking branch 'origin/have_configure'Stefano Pigozzi2013-11-041-1/+1
|\
| * Merge branch 'master' into have_configurewm42013-11-041-30/+93
| |\ | | | | | | | | | | | | Conflicts: configure
| * | configure: uniform the defines to #define HAVE_xxx (0|1)Stefano Pigozzi2013-11-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | | vo_opengl: fix use of uninitialized memorywm42013-11-041-1/+1
| |/ |/| | | | | | | Pretty bad, although it should actually not cause any misbehavior. Comes from the hardware decoding interop commit.
* | vo_opengl: add infrastructure for hardware decoding OpenGL interopwm42013-11-041-30/+93
|/ | | | | | | | | | | | Most hardware decoding APIs provide some OpenGL interop. This allows using vo_opengl, without having to read the video data back from GPU. This requires adding a backend for each hardware decoding API. (Each backend is an entry in gl_hwdec_vaglx[].) The backends expose video data as a set of OpenGL textures. Add infrastructure to support this. The next commit will add support for VA-API.
* Fix some more -Wshadow warningswm42013-11-011-4/+4
| | | | | | These aren't printed with newer gcc or clang versions for some reason. All of them seem to be about local variables shadowing global functions.
* m_config: refactor option defaults handlingwm42013-10-241-0/+10
| | | | | | | | | | | | | Keep track of the default values directly, instead of creating a new instance of the option struct just to get the defaults. Also get rid of the special handling of m_obj_desc.init_options. Instead, handle it purely by the option parser. Originally, I wanted to handle --vo=opengl-hq and --vo=direct3d_shaders with this (by making them aliases to the real VOs with a different preset), but since --vo =opengl-hq=help prints the wrong values (as consequence of the simplification), I'm not doing that, and instead use something different.
* gl_video: add RGB10_A2 FBO formatwm42013-10-231-0/+1
| | | | Maybe this can be the default in the future, but I'm not sure yet.
* video/out: always support redrawing VO window at any pointwm42013-10-021-1/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | Before, a VO could easily refuse to respond to VOCTRL_REDRAW_FRAME, which means the VO wouldn't redraw OSD and window contents, and the player would appear frozen to the user. This was a bit stupid, and makes dealing with some corner cases much harder (think of --keep-open, which was hard to implement, because the VO gets into this state if there are no new video frames after a seek reset). Change this, and require VOs to always react to VOCTRL_REDRAW_FRAME. There are two aspects of this: First, behavior after a (successful) vo_reconfig() call, but before any video frame has been displayed. Second, behavior after a vo_seek_reset(). For the first issue, we define that sending VOCTRL_REDRAW_FRAME after vo_reconfig() should clear the window with black. This requires minor changes to some VOs. In particular vaapi makes this horribly complicated, because OSD rendering is bound to a video surface. We create a black dummy surface for this purpose. The second issue is much simpler and works already with most VOs: they simply redraw whatever has been uploaded previously. The exception is vdpau, which has a complicated mechanism to track and filter video frames. The state associated with this mechanism is completely cleared with vo_seek_reset(), so implementing this to work as expected is not trivial. For now, we just clear the window with black.
* vo_opengl: blend alpha components by defaultwm42013-09-191-4/+10
| | | | | | Improves display of images and video with alpha channel, especially if the transparent regions contain (supposed to be invisible) garbage color values.
* gl_osd: mp_msg conversionwm42013-09-121-1/+1
|
* gl_common: complete mp_msg conversionwm42013-09-121-3/+3
| | | | Hopefully this works on Wayland and Cocoa, which I didn't test.
* gl_video: don't crash if no FBOs are availablewm42013-08-281-4/+6
| | | | | | | | This probably has been broken since bbc865a: a test was added that uses a FBO, but it's always run, even if FBOs were not detected. On the other hand, fbotex_init() just runs into an assert. Fix the test that triggered this condition, and make fbotex_init() "nicer" by just failing if FBOs are not available.
* gl_video: fix odd video sizes with PBOswm42013-08-261-0/+4
| | | | | | | | | Odd video sizes if pixel formats with chroma subsampling and PBOs were used, garbage was rendered. This was because the PBO path created buffers with an unpadded size, and then tried to upload a padded image to it. Fix it by explicitly setting the padded size. (As with the non-PBO path, we rely that image allocations are somehow padded, which is normally the case.)
* video: handle video output levels with mp_image_paramswm42013-08-241-10/+6
| | | | | | | | | | | | Until now, video output levels (obscure feature, like using TV screens that require RGB output in limited range, similar to YUY) still required handling of VOCTRL_SET_YUV_COLORSPACE. Simplify this, and use the new mp_image_params code. This gets rid of some code. VOCTRL_SET_YUV_COLORSPACE is not needed at all anymore in VOs that use the reconfig callback. The result of VOCTRL_GET_YUV_COLORSPACE is now used only used for the colormatrix related properties (basically, for display on OSD). For other VOs, VOCTRL_SET_YUV_COLORSPACE will be sent only once after config instead of twice.
* core: move contents to mpvcore (2/2)Stefano Pigozzi2013-08-061-1/+1
| | | | Followup commit. Fixes all the files references.
* gl_video: handle non-mod-2 4:2:0 YUV video correctlywm42013-08-061-2/+10
| | | | | | | | | | | | | | | | Allocate textures big enough to include the bottom/right borders (so the chroma texture sizes are rounded up instead of down). Make the texture large enough to include the additional luma border. Conceptually, we pretend that the video frame is fully aligned, and then crop away the unwanted borders. Filtering (even just bilinear) will access the borders anyway, so it's possible that we might need to switch to "harder" cropping instead, but at least pixels not close to the border should be displayed correctly now. Add a comment to mp_image.c about this luma border. These semantics are kind of subtle, and the image allocation code handle this in a subtle way too, so it's better to document this explicitly. The libavutil image allocation code does similar things.
* video/out: use new mp_msg stuff for vo.c and vo_openglwm42013-07-311-50/+56
| | | | The first step; also serves as example.
* gl_video: make sure image parameters are correctly set on screenshotswm42013-07-261-7/+8
| | | | Makes sure the chroma_location doesn't get lost.
* 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
| | | | | | | | | | | | | | | | |