summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
* vf_vavpp: provide future/past frames to driverwm42015-06-011-30/+97
| | | | | | | | | | | | | This was missing for extended deinterlacer. Unfortunately, these deinterlacer still do not work. The provided future frame (which is all the deinterlacers want) seems to be correct, though. One minor behavioral change is that this always keeps the previous frame for PTS computations. This could be avoided (in order to keep exactly the same behavior as before), but it seems more elegant and should not do any harm. (Also, if we really cared about reducing hw frame refs, a more worthy goal is producing the field output incrementally.)
* vf_vavpp: move vaMapBuffer() closer to its usewm42015-06-011-4/+4
| | | | | | | | The mapped data (pointed to by the param variable) is not needed before, so the call can be moved down. Also, this prevents that the buffer remains mapped forever if the other vaMapBuffer() call above fails (the cleanup code forgets to unmap the buffer - this commit makes it unnecessary).
* vf_vavpp: remove dummy loop, unindentwm42015-06-011-51/+61
| | | | | | | This used a do-while loop, which runs only once, as replacement for a cleanup goto. While this is ok, doing a goto directly is easier to follow and is closer to idiomatic C. But mainly remove it so that the indentation can be reduced.
* vf_vavpp: cosmeticswm42015-06-011-10/+10
| | | | Adjust coding style. Get rid of some useless consts too.
* vf_vavpp: minor simplificationwm42015-06-011-29/+24
| | | | Slightly easier to follow.
* win32: fix window resize logicwm42015-05-311-2/+3
| | | | | | Reconfiguring with the same video size should never cause the window to resize back to the video size (if the user changed its size). This was broken and it resized anyway.
* vo_opengl: output slightly more debugging info on backend probingwm42015-05-301-0/+2
|
* vo: move up vo_wayland in autoprobe listwm42015-05-301-3/+3
| | | | | When running on Wayland, and vo_opengl is not available or rejected for some reason, it's better to use vo_wayland instead of e.g. vo_x11.
* vf_vavpp: fix bob deinterlacing for bottom field first videosFilip Milivojevic2015-05-301-0/+2
| | | | Signed-off-by: wm4 <wm4@nowhere>
* vf_vavpp: do not pretend to support referenceswm42015-05-291-3/+5
| | | | | | | | | | | | | | | We do not fill them, so we would pass random IDs to the driver. The code was originally written to handle bob deinterlacing only, so I guess it originally passed always 0 anyway, despite having code for reference surface list allocation. Also, move down the vaUnmapBuffer() call. This call actually "unmaps" the param pointer, so accessing it after the unmap call would be undefined behavior. The "example" in <va/vavpp.h> does this too, but it's most likely an error. (Additionally, not even bob deinterlacing worked correctly in my test, sigh.)
* vf_vavpp: simplify surface list allocationwm42015-05-291-14/+2
|
* vo_drm: fix not using BUF_COUNTMarcin Kurczewski2015-05-291-5/+4
|
* vo_drm: fix centering with regard to strideMarcin Kurczewski2015-05-291-13/+16
|
* vaapi: remove direct mapping non-sensewm42015-05-291-42/+6
| | | | | | | | | | | | | | | | | | | | This must have been some non-sense in the original vaapi mplayer patch. While I still have no good idea what this "direct mapping" business is about, it appears to be pretty much pointless. Nothing can hold additional "real" surface references (due to how the API and mpv/lavc refcounting work), so removing the additional surfaces won't break anything. It still could be that this was for achieving additional buffering (not reusing surfaces as soon), but we buffer some additional data anyway. Plus, the original intention of the vaapi mplayer code was probably increasing surface count just by 1 or 2, not actually doubling it, and/or it was a "trick" to get to the maximum count of 21 when h264 is in use. gstreamer-vaapi uses "ref_frames + SCRATCH_SURFACES_COUNT" here, with SCRATCH_SURFACES_COUNT defined to 4. It doesn't appear to check the overlay attributes at all in the decoder. In any case, remove this non-sense.
* vd_lavc: fix a hw decoding fallback casewm42015-05-291-1/+6
| | | | | | | On hw decoder reinit failure we did not actually always return a sw format, because the first format (fmt[0]) is not always a sw format. This broke some cases of fallback. We must go through the trouble to determine the first actual sw format.
* vdpau: do not attempt to allocate surfaces while preemptedwm42015-05-291-10/+17
| | | | | | | | This reduces spam while preempted a bit. The remaining message, "hardware accelerator failed to decode picture" on every frame, can not be prevented because it's hardcoded in libavcodec.
* vo_opengl: avoid broken shader if hwdec fails to provide textureswm42015-05-281-1/+4
| | | | | | | | | | If gl_hwdec_driver.map_image fails, all textures will be set to 0. This in turn makes pass_prepare_src_tex() skip generation of the texture uniforms, which leads to a shader compilation error, as e.g. texture0 is not defined but expected to exist and accessed. Set the textures to an invalid non-0 ID instead. OpenGL can deal with it.
* vdpau: add support for the "new" libavcodec vdpau APIwm42015-05-283-1/+120
| | | | | | | | | Yet another of these dozens of hwaccel changes. This time, libavcodec provides utility functions, which initialize the vdpau decoder and map codec profiles. So a lot of work the API user had to do falls away. This also will give us support for high bit depth profiles, and possibly HEVC once libavcodec supports it.
* video: rename vdpau.c to vdpau_old.cwm42015-05-281-0/+0
| | | | vdpau.c will be used for new code.
* vd_lavc: allocate hw surfaces using the coded sizewm42015-05-281-10/+9
| | | | | | ...instead of relying on the hw decoding API to align it for us. The old method could in theory have gone wrong if the video is cropped by an amount large enough to step over several blocks.
* vdpau: retrieve mixer parameters directly from the hw surfacewm42015-05-283-12/+23
| | | | | | | | | | | | Always configure the vdpau mixer based on the current surface sent to it. Before this, we just hardcoded the chroma type, and the surface size was essentially a guess. Calling VdpVideoSurfaceGetParameters() on every surface is a bit suspicious, but it appears it's a cheap function (just requiring some locks and a table lookup). This way we avoid creating another complicated mechanism to carry around the actual surface parameters with a mp_image/AVFrame.
* vd_lavc: merge two functionswm42015-05-281-27/+15
| | | | | | | There's not much of a reason to keep get_surface_hwdec() and get_buffer2_hwdec() separate. Actually, the way the mpi->AVFrame referencing is done makes this confusing. The separation is probably an artifact of the pre-libavcodec-refcounting compatibility glue.
* vd_lavc: make hardware decoding fallback less violentwm42015-05-282-5/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Most of hardware decoding is initialized lazily. When the first packet is parsed, libavcodec will call get_format() to check whether hw or sw decoding is wanted. Until now, we've returned AV_PIX_FMT_NONE from get_format() if hw decoder initialization failed. This caused the avcodec_decode_video2() call to fail, which in turn let us trigger the fallback. We didn't return a sw format from get_format(), because we didn't want to continue decoding at all. (The reason being that full reinitialization is more robust when continuing sw decoding.) This has some disadvantages. libavcodec vomited some unwanted error messages. Sometimes the failures are more severe, like it happened with HEVC. In this case, the error code path simply acted up in a way that was extremely inconvenient (and had to be fixed by myself). In general, libavcodec is not designed to fallback this way. Make it a bit less violent from the API usage point of view. Return a sw format if hw decoder initialization fails. In this case, we let get_buffer2() call avcodec_default_get_buffer2() as well. libavcodec is allowed to perform its own sw fallback. But once the decode function returns, we do the full reinitialization we wanted to do. The result is that the fallback is more robust, and doesn't trigger any decoder error codepaths or messages either. Change our own fallback message to a warning, since there are no other messages with error severity anymore.
* vo_drm: Expose mode ID option to usersMarcin Kurczewski2015-05-281-10/+19
|
* vo_drm: Fix resolution not restored after exitingMarcin Kurczewski2015-05-281-1/+1
|
* vo_drm: Fix stride problem for certain devicesMarcin Kurczewski2015-05-281-1/+1
|
* vo_opengl: rename use_full_range to use_normalized_rangewm42015-05-271-8/+8
| | | | | As suggested by haasn. The term "full range" makes it sound like it has to do with TV vs. PC range, which is not the case at all.
* vo_opengl: fix source-shader + XYZ inputNiklas Haas2015-05-271-2/+5
|
* vo_opengl: CMS no longer implies linear scalingNiklas Haas2015-05-271-4/+1
| | | | | | | | | | | They're completely orthogonal concepts, merged in the past due to convenience and ease of implementing it in the old #ifdef hell renderer. Especially after the CMS stuff was generalized by 634b4a, this was a trivial change to implement and also means color management will be much higher quality when enabled with vo=opengl (which had quantization issues in the past due to the 8 bit FBO format and upscaling), since it can be done in a single pass now.
* vo_opengl: icc-profile overrides icc-profile-autoNiklas Haas2015-05-271-1/+2
| | | | Signed-off-by: wm4 <wm4@nowhere>
* vo_opengl: add support for custom shadersNiklas Haas2015-05-277-53/+264
|
* vd_lavc: report actually used hwdec APIwm42015-05-252-4/+1
| | | | | Instead of the requested one, which can be just "auto", and which is rather useless.
* vf_dlopen: declare as deprecatedwm42015-05-251-0/+4
| | | | | Mostly to see whether someone uses it, and if a better solution can be worked out. (It's simple enough to be supported forever.)
* cocoa: don't load hardcoded icon if running from bundleStefano Pigozzi2015-05-251-0/+3
| | | Makes ricers happy.
* vo_null: add framerate emulationwm42015-05-241-4/+34
|
* vo_opengl: switch to new OpenGL backend API for icc-profile-autoNiklas Haas2015-05-221-1/+1
| | | | The current code just segfaults.
* vo_opengl: vda: make it work anywherewm42015-05-212-5/+35
| | | | | | | | A rather dumb hack to copy the problematic rectangle textures (mandated by VDA) into 2D ones. (This isn't done yet for OpenGL 3.0+. We need to make sure the performance isn't reduced too much by it.)
* video: do not align source position to 2wm42015-05-212-11/+11
| | | | | vo_direct3d still seems to require this (tested on Windows 8.1 with Intel graphics). Do it in vo_direct3d instead of messing with all VOs.
* vo_opengl: remove npot optionwm42015-05-211-16/+0
| | | | Completely useless.
* vo_xv: make number of buffers configurablewm42015-05-201-3/+8
|
* x11: never forcefully terminate xdg-screensaver processwm42015-05-182-9/+8
| | | | | | It sometimes happens on exit, and it's probably a bad idea. If the process hangs on exit (possibly due to stupid hardcoded timeouts it's doing), mpv will also hang now, unfortunately.
* x11: attempt to make initial fullscreening more reliablewm42015-05-151-0/+3
| | | | | | | | | | | | | | It appears some WMs have a problem with out method of setting initial fullscreen mode. We assume that if the window's _NET_WM_STATE includes _NET_WM_STATE_FULLSCREEN before mapping the window, the WM will show it as fullscreen at mapped. EWMH doesn't say anything that this should work, although one could argue that it's implied. In any case, since it's not standard behavior without at least some doubt, it's probably a good idea to try the "old" method as well. Fortunately, it should be idempotent. See #1937, #1920.
* vf_vapoursynth: reject unaligned video sizeswm42015-05-151-0/+7
| | | | Leads to some nice memory corruption otherwise.
* vo: remove suspicious linewm42015-05-151-1/+1
| | | | | pts can never be 0 or negative. If there is no frame, some code below catches this case by checking hasframe.
* Remove trailing whitespacesMichael Vetter2015-05-152-3/+3
|
* dxva2: support HEVCwm42015-05-141-1/+8
| | | | | | | | | | | | This is pretty much copy&pasted from Libav commit a7e0380497306d9723dec8440a4c52e8bf0263cf. Note that if FFmpeg was not compiled with HEVC DXVA2 support or your video drivers do not support HEVC, the player will not fallback and just fail decoding any video. This is because libavcodec appears not to return an error in this case. The situation is made worse by the fact that MSYS2 is on an ancient MinGW-w64 release, which does not have the required headers for HEVC DXVA2 support.
* vo_opengl: hardcode rquested GL version in backendswm42015-05-146-26/+9
| | | | | The requested version field didn't make much sense anymore, and was even partially ignored by some backends.
* x11: use new OpenGL backend APIwm42015-05-143-24/+34
|
* vo_opengl: create new API for OpenGL VO backendswm42015-05-143-23/+106
| | | | | | | | | | An attempt to get rid of the weird mix of callbacks that take either struct vo or MPGLCopntext as parameter. This is not perfect, and the API will probably change a bit until all other code is ported to it. the main question is how to separate struct vo completely from the windowing code, which actually needs vo for very little. In the end, the legacy callbacks will be dropped.
* vo_opengl: change user options for requesting GLESwm42015-05-146-36/+9
| | | | | | | | Instead of having separate backends, make use of GLES a flag. This reduces the number of backends and the resulting annoyances. Also, nobody cares about using GLES, so there's no backward compatibility either.
* vo_opengl: merge GL backend creation/initializationwm42015-05-131-28/+20
| | | | | The final goal is to remove the nonsense separation between the 3 backend init/vo_init/GL context creation calls.
* vo_opengl: remove mpgl_lock callswm42015-05-133-63/+7
| | | | Awkward stuff not needed anymore.
* cocoa: redo synchronizationwm42015-05-133-169/+156
| | | | | | | | | | | | | | | | | | | | | Before this change, Cocoa state was accessed from both the VO and the Cocoa main thread. This was probably not a good idea. There was some locking as well as implicit synchronization using the dispatch mechanism, but it wasn't watertight. Change this completely. Now Cocoa things are always accessed from the main thread only. The old mutex falls away, as well as the vo_cocoa_set_current_context() function, which implicitly used the lock to coordinate VO accesses. With the new code, the VO thread generally has to wait for the main thread, while the main thread never waits for the VO and rarely accesses it. Fortunately, this is rather straight forward, and most of this is achieved by making vo_cocoa_control() run on the main thread. The logic of the code does generally not change. Some aspects are trickier. Apparently we can't access the NSOpenGLContext from the VO thread, because this object is not thread- safe. We use some CGLContextObj functions instead, such as for making the context current and swapping the buffers.
* vo_opengl: remove some more Cocoa resize leftoverswm42015-05-134-31/+0
|
* vda: add support for nv12 image formatsStefano Pigozzi2015-05-132-21/+108
| | | | | | | | | The hardware always decodes to nv12 so using this image format causes less cpu usage than uyvy (which we are currently using, since Apple examples and other free software use that). The reduction in cpu usage can add up to quite a bit, especially for 4k or high fps video. This needs an accompaning commit in libavcodec.
* vo: avoid burning CPU when pausedwm42015-05-131-1/+2
| | | | | | Some code always calls vo_event(), even with event==0, which leads to immediate wakeup, which in turn causes the function to be called again. This would burn CPU, which was especially noticeable when paused.
* cocoa: make live-resizing as fast as beforewm42015-05-123-9/+14
| | | | | | | | | | | Interrupt video timing. This means the Cocoa event loop does not have to up to 2 video frame durations until redrawing the frame finally has finished. We abuse the VO event flags for this. Eventually this should use wait_vo() or so in the video timing wait function, but for now the interaction this would require with the code of other VOs/backends would cause too much of a mess.
* cocoa: handle live-resizing differentlywm42015-05-123-42/+41
| | | | | | | | | | | | | | | | | | Instead of requiring a complicated mechanism to share the entire OpenGL and renderer state between VO and Cocoa thread just to do the redrawing during live-resize on the Cocoa thread, let the Cocoa thread wait on the VO thread. This wil allow some major simplifications and cleanups in the future. One problem with this is that it can enter a deadlock whenever the VO tries to sync with the Cocoa thread. To deal with this, the Cocoa thread waits with a timeout. This can probably be improved later, though in general this situation can always happen, unless the Cocoa thread waits in a reentrant way. Some other details aren't completely clean either. For example, pending_events should be accessed atomically. This will also be fixed later.
* vo: use pthread_cond_timedwait() for video timingwm42015-05-121-6/+17
| | | | | | | | | | | | | | | | Will be used to make video waiting interruptible with Cocoa (see the following commit). One worry was that this could cause hangs if the system clock jumps backwards. Normally we don't support such behavior, because it's almost impossible to handle it reasonably. E.g. we would have to change the default clock type for condition variables, which in turn would require a custom function for creating condition variables, or so. If the OS even supports different clocks. But it turns out that this is no issue, because other events seem to wakeup the wait call anyway, and mpv internal absolute times use a monotonic clock.
* vo_opengl_cb: add support for interpolationwm42015-05-121-5/+51
| | | | | | | | | | | | | | | | | This uses the OpenGL frame interpolation code, which before could be used by vo_opengl only. Some effort was made to make it behave like vo_opengl, for the better or the worse. As a consequence, there is a minor duplication of code and mechanism. Hopefully this can all be wiped as soon as the VO frame queue/timing mechanism is cleaned up. This also attempts to use mpv_opengl_cb_report_flip() (as called by the API user) to determine the vsync interval. This might need refinement as well. (In general, we simply expect the API user to work in vsync-blocking manner.)
* vo_opengl_cb: add a "block" framedrop mode and make it defaultwm42015-05-121-5/+27
| | | | | | | | | (I have no idea why there are different modes.) Instead of risking to drop frames too early, give it some margin. Since there are situations this could deadlock, wait with a timeout. This can happen if e.g. the API user is refusing to render anything, or if uninitialization is happening.
* vo_opengl_cb: actually set requested optionswm42015-05-121-0/+1
| | | | Quite an oversight.
* vo: always call draw_image_timed() if availablewm42015-05-121-1/+1
| | | | | | | Gives the VOs more flexibility. gl_video.c already ignores the timing info if no interpolation is active, so this requires no further changes.
* threads: use utility+POSIX functions instead of weird wrapperswm42015-05-111-2/+4
| | | | | | | There is not much of a reason to have these wrappers around. Use POSIX standard functions directly, and use a separate utility function to take care of the timespec calculations. (Course POSIX for using this weird format for time values.)
* cocoa: remove unused declarationwm42015-05-111-3/+0
|
* cocoa: add missing break statements in switchwm42015-05-111-0/+2
| | | | | The first one (for VOCTRL_GET_DISPLAY_FPS) could have led to undefined behavior if the FPS was unknown. Th