summaryrefslogtreecommitdiffstats
path: root/video/out
Commit message (Collapse)AuthorAgeFilesLines
* vo_opengl: move gl_* files to their own subdirNiklas Haas2015-09-0926-24/+24
| | | | | This is mainly just to keep things a bit more organized and separated inside the codebase.
* vo_opengl: minor refactorNiklas Haas2015-09-091-5/+5
| | | | | Just making the argument order for pass_load_fbotex more consistent with finish_pass_fbo.
* vo_opengl: filter allowed options in dumb-modewm42015-09-081-14/+14
| | | | | | | Instead of the other way around of disabling disallowed options. This is more robust and also slightly simpler, at least conceptually. If new vo_opengl features are added, they don't need to be explicitly disabled for dumb-mode just to avoid that it accidentally breaks.
* vo_opengl: move gl_video_opts copying code to separate functionwm42015-09-082-15/+22
| | | | | | | | | | Sigh... Hopefully this code will be completely unnecessary one day, as it's only needed due to the sub-option parser craziness. Move dumb_mode to the top of the struct, so the C universal initializer doesn't cause warnings with all those broken compilers.
* vo_opengl: restore single pass optimization as separate code pathwm42015-09-072-30/+78
| | | | | | | | | | | | | | | | | | | | | | The single path optimization, rendering the video in one shader pass and without FBO indirections, was removed soem commits ago. It didn't have a place in this code, and caused considerable complexity and maintenance issues. On the other hand, it still has some worth, such as for use with extremely crappy hardware (GLES only or OpenGL 2.1 without FBO extension). Ideally, these use cases would be handled by a separate VO (say, vo_gles). While cleaner, this would still cause code duplication and other complexity. The third option is making the single-pass optimization a completely separate code path, with most vo_opengl features disabled. While this does duplicate some functionality (such as "unpacking" the video data from textures), it's also relatively unintrusive, and the high quality code path doesn't need to take it into account at all. On another positive node, this "dumb-mode" could be forced in other cases where OpenGL 2.1 is not enough, and where we don't want to care about versions this old.
* vo_opengl: move video source rectangle computation to a functionwm42015-09-071-18/+29
| | | | Needed for the following commit.
* vo_opengl: comsetics: remove unnecessary line breakwm42015-09-071-4/+2
|
* vo_opengl: require FBOs and get rid of the single-pass optimizationNiklas Haas2015-09-071-82/+34
| | | | | | | This change makes vo_opengl slightly less compatible (ancient devices without FBOs will no longer work) and decreases performance in the simplest case (vo=opengl), in exchange for significantly reducing code complexity and making everything easier to reason about.
* vo_opengl: use the correct attribute name for vertex positionwm42015-09-041-2/+2
| | | | | | This didn't seem entirely sane. It probably worked by accident, because "position" is always the first attribute, and thus the default value 0 for the location was always correct.
* vo_opengl: improve robustness against PBO failurewm42015-09-021-29/+40
| | | | | | | | | | | | | | If PBO upload fails, disable PBOs and revert to the normal codepath. In theory we should retry PBO upload on failure (because OpenGL specifies that it can sporadically fail), but since it normally doesn't happen, and the fallback will work, I'm not bothering. Some restructuring is needed, since glUnmapBuffer needs to be called earlier. In fact, the old code structure didn't make too much sense, and is a leftover from MPlayer's direct rendering support, which let the decoder decode to a PBO-mapped region. This means the buffer_ptr field can be dropped. Drop buffer_size as well, since it only had 2 possible values (0 or the size required for the current config).
* vo_opengl: enable pbo by default with opengl-hqwm42015-09-021-0/+1
| | | | | | | | | Can significantly help with very large video resolutions on nvidia drivers. It doesn't seem to have negative effects on Intel drivers either. (Although it could have on Intel drivers for older hardware.) For now, this is only for --vo=opengl-hq. Maybe --vo=opengl should use it too, but it's still meant to be the crappy, fail-safe default.
* vo_opengl: slightly simplify plane size determinationwm42015-09-021-2/+5
| | | | | | | | Setup a dummy image for the given image params, and get the plane sizes from that. Admittedly not much of a simplification, but conceptually it's simpler and less error-prone, as the image layout is guaranteed to be the same, rather than essentially duplicating the way it is determined.
* vo_opengl: don't distinguish "real" and texture sizewm42015-09-023-34/+28
| | | | | | | | This is from times when we supported padded/non-NPOT textures. The difference is not useful anymore, and theoretical support for different sizes is most likely buggy and unmaintained. So remove it. Also remove the tex_ prefix wherever it appears.
* vo_opengl: simplify PBO copywm42015-09-021-6/+2
| | | | | | | | Use mp_image_copy() instead of copying manually. (This function checks whether the destination is regarded writeable, which it is not, because the destination is the source image with changed pointers, so refcounting has to be removed from the destination image by resetting mpi->bufs.)
* vo_opengl: rename get_image to map_imagewm42015-09-021-2/+2
|
* vo_opengl: remove redundant statement in PBO codewm42015-09-022-5/+0
| | | | | | | | This shouldn't be needed anymore. Textures are now always allocated with the exact size. Any padding (including non-NPOT support) is gone. The texture sizes will always match the memory plane sizes. Drop the unused and forgotten "npot" field from the option struct too.
* vo_opengl: remove some leftoverswm42015-09-011-4/+0
| | | | Forgotten in the previous commit.
* vo_opengl, vda: return to old statewm42015-09-012-31/+5
| | | | | | | | Undo 292266f2. Reapply 3e12e79b. An additional copy is not really justified, as it could reduce performance. On the other hand, we can force API users to create a GL 3.x context.
* vo_rpi, vo_opengl: do not globally terminate EGL on VO uninitwm42015-08-311-2/+1
| | | | | | | | | eglTerminate() affects the EGLDisplay in all threads. Since the RPI firmware apparently only ever uses EGL_DEFAULT_DISPLAY, this means it will trash all other contexts on other threads in the same process. Thus we don't call eglTerminate() at all, at least on RPI. Call eglReleaseThread() instead (which may or may not be a NOP).
* vo_opengl: fix alpha video in one casewm42015-08-301-0/+2
| | | | | | | | | yuva444p worked, yuva420p didn't. This happened because the chroma pass discards the alpha plane, which is referenced by the alpha blend code later. Add a terrible hack to work this around, actually using the same hack as was used for the Y plane. (A terrible hack for terrible code.)
* w32: shift drag and drop appendsKevin Mitchell2015-08-301-2/+4
| | | | use the append to playlist functionality if shift is pressed while dropping
* x11: drag and drop append with modifierKevin Mitchell2015-08-302-1/+8
| | | | | | | If the drag and drop action is anything other than XdndActionCopy, append the dropped files rather than replacing the existing playlist. With most file managers, this will mean at least pressing shift while dropping.
* input: add append argument to file drop eventKevin Mitchell2015-08-303-4/+5
| | | | | | This puts in place the machinery to merely append dropped file to the playlist instead of replacing the existing playlist. In this commit, all front-ends set this to false preserving the existing behaviour.
* vo_opengl: force redraw when framestepping with interpolationwm42015-08-251-1/+3
| | | | | | | | | | | | | | | | This might fix some problems when framestepping with interpolation enabled. The problem here is that we want to show the non-interpolated frame while paused. Framestepping is like unpausing the video for a frame, and then pausing again. This draws an interpolated frame, and redrawing on pausing is supposed to take care of this. This possibly didn't always work, because vo->want_redraw is not checked by the vo_control() code path. So wake up the VO thread (which takes care of servicing redraw requests, kind of) explicitly. The correct solution is getting rid of the public-writable want_redraw field and replacing it with a new vo_request_redraw() function, but this can come later.
* vda, videotoolbox: guard against unexpected pixel formatwm42015-08-231-0/+4
| | | | | | Should not happen, but since we don't control decoder video surface allocation, anything could happen, and the code should be able to deal with it. Untested.
* vda, videotoolbox: fix broken condition in screenshot codewm42015-08-231-1/+1
| | | | Fixes #2237.
* vo_opengl: remove dead codewm42015-08-221-9/+0
| | | | Leftover from 3245bfef.
* gl_wayland: Wait for frame callbacksJari Vetoniemi2015-08-211-0/+5
| | | | | Keep glSwapInterval(0) on to avoid blocking on gl calls, but wait for frame callbacks so we play nice with compositor.
* vo_wayland: Wait for frame callbacksJari Vetoniemi2015-08-213-18/+84
| | | | | | | Privdes small api for vo_wayland where one can request frame callback and then wait for it. This will make vo_wayland play video smoothly.
* gl_wayland: eglSwapInterval(0) to avoid blockingJari Vetoniemi2015-08-213-18/+14
| | | | This makes mesa not wait for frame callback internally.
* vo_opengl: add tscale-clamp optionNiklas Haas2015-08-204-2/+9
| | | | | | | | | | This significantly reduces the amount of noticeable flashing when using tscale kernels with negative lobes, by cutting them off completely. I'm not sure if this has any negative effects. It needs a bit of subjective testing over a period of time, so I just made it an option. Fixes #2155.
* vo_rpi: disable background by defaultwm42015-08-201-6/+13
| | | | And add an option to enable it.
* gl_rpi: destroy the EGLSurface toowm42015-08-201-2/+5
| | | | Most likely doesn't matter much.
* vo_rpi: use correct variable for osd layerwm42015-08-201-1/+1
| | | | | This is a cosmetic change, because the value is exactly the same. (The old code just duplicates the logic, sort of.)
* vo_rpi: fix blackscreen before the first subtitle/OSD is renderedwm42015-08-201-0/+1
| | | | | The OSD overlay wasn't initialized, so it remained solid black until the first time a subtitle line or an OSD element became visible.
* vo_rpi: redraw subtitles only on changewm42015-08-183-4/+33
| | | | | | | | | | | Since vo_rpi uses MMAL for video output, which is completely independent from the GLES overlay, we can just not redraw the GLES screen if subtitles do not change. (As a furhter optimization, the dispmanx overlay could be removed if nothing is visible. But I'm not sure if adding and removing the overlay frequently is a good idea for performance, so this could just as well go the other way.)
* vo_rpi: use EGL to render subtitleswm42015-08-183-125/+85
| | | | | | | | Slightly faster than using the dispmanx mess (perhaps to a large amount due to the rather stupid C-only unoptimized ASS->RGBA blending code). Do this by reusing vo_opengl's subtitle renderer, and vo_opengl's RPI backend.
* rpi: factor out context creationwm42015-08-182-63/+108
| | | | To be used by vo_rpi.c. No functional changes.
* video: fix VideoToolbox/VDA autodetectionwm42015-08-172-40/+7
| | | | | | | | | | | | | | | This affects vo_opengl_cb in particular: it'll most likely auto-load VDA, and then the VideoToolbox decoder won't work. And everything fails. This is mainly caused by FFmpeg using separate pixfmts for the _same_ thing (CVPixelBuffers), simply because libavcodec's architecture demands that hwaccel backends are selected by pixfmts. (Which makes no sense, but now we have the mess.) So instead of duplicating FFmpeg's misdesign, just change the format to our own canonical one on the image output by the decoder. Now the GL interop code is exactly the same for VDA and VT, and we use the VT name only.
* vo_rpi: fix NULL pointer derefwm42015-08-141-1/+1
| | | | Can happen in obscure situations and with hw decoding disabled.
* vo_rpi: simplify background handlingwm42015-08-131-19/+1
| | | | Apparently this is sufficient.
* vo_rpi: unregister vsync callbackwm42015-08-131-1/+3
| | | | Small bug, much pain.
* vo_rpi: skip OSD rendering when repeating frameswm42015-08-131-4/+8
| | | | It's unnecessary and slow. Doesn't help too much, though.
* vo: fix video EOF with display-syncwm42015-08-121-2/+2
| | | | | | | We must not use the frame PTS in any case. In this case, it fails because nothing sets it up to wake up. This typically caused the player to apparently "pause", until something else waked it up, like moving the mouse and other events.
* cocoa: hide cursor using a blank image instead of a system-wide APIRodger Combs2015-08-111-4/+14
| | | | Fixes #503
* vo_rpi: support display syncwm42015-08-101-4/+51
| | | | | | | | This VO is special because it normally doesn't block on vsync, but can be made to do so. Supposedly the MMAL video output API merely sets a "current frame" field when sending an output frame, and the firmware will pick up whatever frame that field is set to at the time of a vsync.
* player: add display sync modewm42015-08-102-10/+84
| | | | | | | | | | | | | | | | | | | | | | | | If this mode is enabled, the player tries to strictly synchronize video to display refresh. It will adjust playback speed to match the display, so if you play 23.976 fps video on a 24 Hz screen, playback speed is increased by approximately 1/1000. Audio wll be resampled to keep up with playback. This is different from the default sync mode, which will sync video to audio, with the consequence that video might skip or repeat a frame once in a while to make video keep up with audio. This is still unpolished. There are some major problems as well; in particular, mkv VFR files won't work well. The reason is that Matroska is terrible and rounds timestamps to milliseconds. This makes it rather hard to guess the framerate of a section of video that is playing. We could probably fix this by just accepting jittery timestamps (instead of explicitly disabling the sync code in this case), but I'm not ready to accept such a solution yet. Another issue is that we are extremely reliant on OS video and audio APIs working in an expected manner, which of course is not too often the case. Consequently, the new sync mode is a bit fragile.
* hwdec: add VideoToolbox supportSebastien Zwickert2015-08-052-11/+51
| | | | | | | | VDA is being deprecated in OS X 10.11 so this is needed to keep hwdec working. The code needs libavcodec support which was added recently (to FFmpeg git, libav doesn't support it). Signed-off-by: Stefano Pigozzi <stefano.pigozzi@gmail.com>
* vo_vdpau: fix frame scheduling if display FPS is unknownwm42015-08-042-3/+3
| | | | | | | | | | | Pretty stupid: vo_get_vsync_interval() returns a negative value if the display FPS is unknown (e.g. xrandr not compiled), and the comparison whether the value is below 0 fails later because it's assigned to an unsigned int. Regression since commit e3d85ad4. Also, fix some comments in vo.c.
* vo: fix inverted conditionwm42015-08-031-1/+1
| | | | | | | | When full_redraw is set, we always need to take the draw_image path. If it's not set, we can try VOCTRL_REDRAW_FRAME (and fallback to draw_image if that fails). Fixes #2184.
* vo: correctly account for dropped frameswm42015-08-011-4/+4
| | | | | | If the framedrop count happens to be incremented with vo_increment_drop_count() during rendering, these increments were counted twice, because these events also set in->dropped_frame.
* vo_opengl: minor simplificationswm42015-08-011-4/+2
| | | | No functional changes.
* win32: revert wchar_t changeswm42015-08-012-11/+11
| | | | | | | | | | | Revert "win32: more wchar_t -> WCHAR replacements" Revert "win32: replace wchar_t with WCHAR" Doing a "partial" port of this makes no sense anymore from my perspective. Revert the changes, as they're confusing without context, maintenance, and progress. These changes were a bit premature anyway, and might actually cause other issues (locale neutrality etc. as it was pointed out).
* win32: more wchar_t -> WCHAR replacementswm42015-07-302-4/+4
| | | | | | | | | | | | | This was essentially missing from commit 0b52ac8a. Since L"..." string literals have the type wchar_t[], we can't use them for UTF-16 strings. Use C11 u"..." string literals instead. These have the type char16_t[], but we simply assume char16_t is the same underlying type as WCHAR. In practice, they're both unsigned short. For this reason use -std=c11 on Windows. Since Windows is a "special" environment (we require either MinGW or Cygwin), we don't need to worry too much about compiler compatibility.
* vo_direct3d: create multithreaded IDirect3DDevice9wm42015-07-301-1/+2
| | | | | | | | | | | | | | | A user complains that it leads to the dxva driver failing, leading to messages like this: [ffmpeg/video] h264: Failed to execute: 0x8007000e [ffmpeg/video] h264: hardware accelerator failed to decode picture Reportedly, this happens only with vo_direct3d, not with vo_opengl. The only difference is that vo_direct3d attempts to share the D3D device with the decoder. Possibly the error is that the device in the VO is not created with D3DCREATE_MULTITHREADED. Change this. Probably fixes #2178.
* win32: replace wchar_t with WCHARwm42015-07-291-8/+8
| | | | | | | | | | | | | WCHAR is more portable. While at least MinGW, Cygwin, and MSVC actually use 16 bit wchar_t, Midipix will have 32 bit wchar_t. In that context, using WCHAR instead is more portable. This affects only non-MinGW parts, so not all uses of wchar_t need to be changed. For example, terminal-win.c won't be used on Midipix at all. (Most of io.c won't either, so the search & replace here is more than necessary, but also not harmful.) (Midipix is not useable yet, so this is just preparation.)
* vo_opengl: framebuffers work under GLES 2wm42015-07-271-1/+1
| | | | | They are not entirely full-featured in GLES 2, but they appear to provide all we need. Thus we can enable them.
* vo_opengl: slightly more informative message when disabling scalerswm42015-07-271-4/+4
|
* vo_rpi: determine and return display refresh ratewm42015-07-271-0/+24
| | | | Reverse engineered from tvservice.c.
* vo_opengl: minor cleanup to hwdec texture setting codewm42015-07-261-14/+9
| | | | | | Instead of special-casing hwdec in the place where the video textures are used, just set the textures in the image upload function. The renderer code doesn't need to know whether hwdec interop is used at all.
* vo_opengl: remove legacy GL detectionwm42015-07-241-23/+1
| | | | | | | | | | This detected whether an OpenGL context still provided legacy OpenGL if the OpenGL version is modern (>= 3.0). This was actually only needed for vo_opengl_old, because it relied on legacy functions. Since it's gone, this code isn't needed either. (Also, the removed comment about OpenGL 3.0 was wrong: you could just query GL_CONTEXT_FLAGS and see if the forward compatible bit was set.)
* vo_opengl: fix scale=oversample's threshold calculationsNiklas Haas2015-07-231-1/+1
| | | | | This resulted in wrong behavior for values of scale-param1 between 0.0 and 0.5 (not inclusive).
* Revert "vo_opengl: make the size of interpolation textures exact"wm42015-07-221-2/+2
| | | | | | | | | | This reverts commit fb8d15836695e883355c5ec6ff8463e7bbf39461. Reallocating the FBOs on every resize is very slow. It affects resizing the window, as well as changing the video size itself with e.g. panscan. Since the original change was done based on a single user complaint, but the change itself caused a lot of complaints, we decided to just revert it.
* vo: minor simplification for queue size handlingwm42015-07-204-15/