summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
* hwdec: add VideoToolbox supportSebastien Zwickert2015-08-058-11/+176
| | | | | | | | 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.
* image_writer: don't use jpeg baseline, and remove useless jpeg optionswm42015-08-021-6/+1
| | | | | | | | | The jpeg-optimize and jpeg-baseline options were undocumented, and they're also pretty useless. There's no reason to ever change them. Also, don't write jpeg baseline images. This just makes compression worse for the sake of rather questionable compatibility with ancient decoders.
* 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-013-13/+13
| | | | | | | | | | | 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-303-6/+6
| | | | | | | | | | | | | 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).
* video: don't restrict --vd-lavc-threads to a maximum of 16wm42015-07-231-1/+1
| | | | | | Only do it when the number of threads is autodetected, as more than 16 threads are still considered not recommended. (libavcodec prints a warning.)
* 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.
* vf_scale: cleanup log messageswm42015-07-201-12/+3
| | | | In particular, get rid of the EUSERBROKEN message.
* vo: minor simplification for queue size handlingwm42015-07-204-15/+14
| | | | | | | | | | Instead of calling it "future frames" and adding or subtracting 1 from it, always call it "requested frames". This simplifies it a bit. MPContext.next_frames had 2 added to it; this was mainly to ensure a minimum size of 2. Drop it and assume VO_MAX_REQ_FRAMES is at least 2; together with the other changes, this can be the exact size of the array.
* vo_opengl: add temporal-dither-period optionNiklas Haas2015-07-202-1/+5
| | | | | This was requested multiple times by users, and it's not hard to implement and/or maintain.
* vo_opengl: make oversample the default for opengl-hq as wellNiklas Haas2015-07-201-1/+1
| | | | | This was supposed to have changed back when oversample was reintroduced in 3007250. Fixes #2155.
* vf_vapoursynth: relicense to LGPL 2.1+wm42015-07-191-7/+7
| | | | | | | | | This was requested by someone. All code was written by myself; some minor changes by 2 contributors who agreed to general LGPL relicensing. 1 line of code is by someone unknown who possibly wasn't asked (setting the "display_fps" variable), and which can be reasonably ignored as it makes up only 0.1% of the file.
* vo_opengl: make the size of interpolation textures exactNiklas Haas2015-07-181-2/+2
| | | | | | | | | | | | I still have no idea why this is needed, maybe some weird off-by-one in some shitty driver? Either way, the difference for a working setup shouldn't be too major, the most noticeable effect would be somewhat worse performance when resizing the video during playback with interpolation enabled using the mouse. That's a specific enough side effect for me to not care as much about it. Fixes #1814.
* screenshot: don't write PNG colorspace tags by defaultwm42015-07-181-1/+1
| | | | | | Generates too much discussion and confusion. Fixes #2051.
* vo_opengl: cleanup frame reupload logicwm42015-07-171-8/+9
| | | | | | | | There are some situations when redrawing is requested, but the current frame was deleted. This could happen when switching e.g. hw decoding mid-stream. Separate uploading/drawing and fix the condition.
* vo_opengl: refactor queue configurationwm42015-07-164-23/+29
| | | | | | | Just avoid some code duplication. Also, gl_video_set_options() having a queue size output parameter is weird at best. While I don't appreciate that this commit suddenly requires gl_video.c to deal with vo.c directly in a special case, it's simply the best place to put this function.
* vo: fix number of future frameswm42015-07-162-2/+2
| | | | | | That was 2 too many. Also fix a documentation comment.
* vo_opengl: reject future images in different formatswm42015-07-151-1/+2
| | | | | | | | | | | | | The VO will be provided with future frames even if the format changes mid-stream. This caused a crash if these frames were actually used (i.e. interpolation mode was enabled). Fixes a crash when deinterlacing is toggled during playback, and the deinterlacer changes the stream format (as it can happen e.g. if the decoder outputs nv12, which in turn happens with hw decoding). (On a side note, future frames are always non-NULL. Also, the current frame is of course always in the correct format.)
* vaapi: destroy derived VAImage after each usewm42015-07-151-0/+4
| | | | Appears to be required by some hardware. Whatever.
* vo_vaapi: drop unused fieldwm42015-07-151-2/+0
|
* vaapi: don't assume vaQueryImageFormats() returns sorted listwm42015-07-151-8/+13
| | | | | | | | | | | | | vaQueryImageFormats() returns a randomly ordered list - so we shouldn't assume the first format on the list which works is the best. This effectively switches to nv12 instead of yuv420p on some drivers. We handle this by reusing va_to_imgfmt[], and ordering it by preference. We hardcode that GPUs prefer nv12 pver yuv420p. In theory we could do complicated probing (allocate dummy surface + use vaDeriveImage on it, then retrieve the FourCC) - but all things which could break assumption in the future are not supported yet (like 10 bit or 4:4:4), so this is fine.
* Revert "vaapi: remove vaDeriveImage() code path"wm42015-07-151-17/+40
| | | | | | This reverts commit d660e67be9cc7d79d81e0c09c2720ea6d0a35e3a. Fixes #2123.
* vaapi: allow allocating additional surfaces during decodingwm42015-07-151-3/+2
| | | | | | | | | | | | | Fixes problems with --vo=opengl:interpolation. The issue here is that vo_opengl retains more surfaces than what was preallocated for the decoder. Until now, we just explicitly failed to decode frames for which no additional surfaces are available. Since modern drivers usually are fine with not "registering" surfaces before the decoder is created, just allow allocating additional surfaces if needed. (We also could probably recreate the HW decoder, since the HW decoder should be stateless. But let's try to avoid raising the overall complexity of the code.)
* vo_opengl: simplifywm42015-07-151-26/+11
| | | | | After recent changes, there is no reason why gl_video_set_image() should exist anymore. So merge it back into gl_video_upload_image().
* vf_vdpaupp: Don't crash when evaluating interlacing of NULL mpiPhilip Langdale2015-07-141-1/+1
| | | | | | | The interlaced frame test needs to be aware that the input mpi might be NULL - this happens at the end of a stream when the input frames have all been submitted but frames still need to be drained from the decoder.
* vo_opengl: reduce verbose outputwm42015-07-111-26/+2
| | | | | | | | | Outputting the detected OpenGL features was useless and redundant with the extension loading output. Also, remove MPGL_CAP_3D_TEX from OpenGL(ES) 3.0. This block didn't include the glTexImage3D function, so that was pointless and couldn't have worked. The OpenGL 2.1 block does it correctly.
* vo_vdpau: Implement rotation supportPhilip Langdale2015-07-111-8/+84
| | | | | | | | | | | | | | | | | | | | VDPAU has explicit support for rotating surfaces, and it is far less expensive than using the normal rotation filter (which would require reading video frames back into system memory), it is desirable to implement the VO rotation capability. To do this, we need to render the video frames to an output surface, without rotation, and then render from that surface to the final output surface to apply the rotation. It is important that the intermediate surface is the same size as the final one (only not rotated) so that hqscaling can be applied if requested by the user. (hqscaling is a mixer capability and so takes effect when the video surface is rendered to an output surface) Finally, we must remember to explicitly clear the final output surface as VDPAU only auto-clears output surfaces when rendering video surfaces.
* vo_opengl: reimplement tscale=oversampleNiklas Haas2015-07-111-9/+32
| | | | Closes #2102.
* vf_vdpaurb: Add a new filter for reading back vdpau decoded framesPhilip Langdale2015-07-112-0/+114
| | | | | | | | | | | | | | | | | Normally, vdpau decoded frames are passed directly to a suitable vo (vo_vdpau or vo_opengl) without ever touching system memory. This is efficient for output purposes, but prevents any of the regular filters from being used with such frames. This new filter implements a read-back step to pull the frames back into system memory where they can be acted on by other filters. Eventually the frames will be sent to the vo as if they were normal software-decoded frames. Note that a vdpau compatible vo must still be used to ensure that the decoder is properly initialised. Signed-off-by: wm4 <wm4@nowhere>
* video: add a way to disable automatic stereo conversionwm42015-07-101-0/+1
| | | | Fixes #2111.
* vf_stereo3d: drop internal implementationwm42015-07-101-393/+15
| | | | Leave the libavfilter wrapper only.
* gl_hwdec: change wording in verbose messagewm42015-07-101-1/+1
|
* vf_vdpaupp: don't attempt to deinterlace progressive frameswm42015-07-081-5/+9
|
* mp_image: fix vf_vdpaupp referenceswm42015-07-081-2/+0
| | | | | | | | | | Some code called by vf_vdpaupp.c calls mp_image_new_custom_ref(), but out of convenience doesn't reset the buffers. Make this behavior ok. (The assert() was there to catch usage errors, but the same error could already happen before the refcount changes were made, so the check is not overly helpful.) Fixes #2115.
* vaapi: drop compatibility crap and vo_vaapi deinterlacerwm42015-07-084-96/+15
| | | | | | | | | | | Drop libva versions below 0.34.0. These are ancient, so I don't care. Drop the vo_vaapi deinterlacer as well. With 0.34.0, VPP is always available, and deinterlacing is done with vf_vavpp. The vaCreateSurfaces() function changes its signature - actually it did in 0.34.0 or so, and the <va/va_compat.h> defined a macro to make it use the old signature.
* vf_vavpp: don't attempt to deinterlace progressive frameswm42015-07-081-0/+7
|
* vaapi: increase number of additional surfaceswm42015-07-081-6/+2
| | | | | | | | | | | | | | | | | | | Sometime recently, hardware decoding started to fail if h264 with full reference frames was decoded, and --vo=vaapi was used. VAAPI requires registering all surfaces that the decoder will ever use in advance, so if the playback chain uses more surfaces than originally allocated, we fail and drop back to software decoding. I'm not really sure why or when this started happening. Commit 7b9d7265 for one is not the cause - it can be reproduced with earlier commits. It also seems to be timing dependent. Possibly it has to do with the way vo.c retains previous surfaces, and the way they can be queued/unqueued asynchronously. Increasing the number of reserved additional surfaces by 1 fixes it. (Though I have no idea where exactly all these surfaces are being used. Or rather, _when_.)
* vf_yadif: expose interlaced frame modewm42015-07-071-9/+5
| | | | | Also remove the enabled suboption, which did nothing. (It was probably broken at some point.)
* vo_opengl_cb, vo_opengl: add option for preloading hwdec contextwm42015-07-074-14/+21
| | | | | | | | See manpage additions. This is mainly useful for vo_opengl_cb, but can also be applied to vo_opengl. On a side note, gl_hwdec_load_api() should stop using a name string, and instead always use the IDs. This should be cleaned up another time.
* options: cleanup hwdec name mappingswm42015-07-071-1/+6
| | | | | | | | | Now there's a "canonical" table for mapping the names, that other code can use, without having to rely too much on option code magic. Also, use the central HWDEC constants, instead of magic values. (There used to be semi-ok reasons to do this, but now it makes no sense anymore.)
* vo_opengl_cb: drop frames eagerly if frames are not renderedwm42015-07-071-1/+7
| | | | | libmpv users might stop calling the frame render callback for stupid reasons, at which point video frames would pile up.
* dxva2: fix handling of cropped videowm42015-07-061-1/+5
| | | | | | Basically, we need to make sure to allocate enough data for the pretty dumb copy_nv12 function. (It could be avoided by making the function less dumb, but this fix is simpler.)
* video: replace our own refcounting with libavutil'swm42015-07-054-150/+123
| | | | | | | | | | | | | | | | | | | | | | mpv had refcounted frames before libav*, so we were not using libavutil's facilities. Change this and drop our own code. Since AVFrames are not actually refcounted, and only the image data they reference, the semantics change a bit. This affects mainly mp_image_pool, which was operating on whole images instead of buffers. While we could work on AVBufferRefs instead (and use AVBufferPool), this doesn't work for use with hardware decoding, which doesn't map cleanly to FFmpeg's reference counting. But it worked out. One weird consequence is that we still need our custom image data allocation function (for normal image data), because AVFrame's uses multiple buffers. There also seems to be a timing-dependent problem with vaapi (the pool appears to be "leaking" surfaces). I don't know if this is a new problem, or whether the code changes just happened to cause it more often. Raising the number of reserved surfaces seemed to fix it, but since it appears to be timing dependent, and I couldn't find anything wrong with the code, I'm just going to assume it's not a new bug.
* mp_image: make image writeable before overwriting palettewm42015-07-051-2/+4
| | | | This is an obscure but theoretically possible bug.
* vo: free frames before killing VOwm42015-07-041-1/+1
| | | | | | This caused issues with hardware decoding. The VOs by definition dictate the lifetime of the hardware context, so no surface allocations must survive the VO. Fixes assertions on exit with vdpau.
* vo: set correct frame parameters on redrawwm42015-07-031-2/+2
|
* client API, dxva2: add a workaround for OpenGL fullscreen issueswm42015-07-035-0/+80
| | | | | | | | | This is basically a hack for drivers which prevent the mpv DXVA2 decoder glue from working if OpenGL is in fullscreen mode. Since it doesn't add any "hard" new API to the client API, some of the code would be required for a true zero-copy hw decoding pipeline, and sine it isn't too much code after all, this is probably acceptable.
* vo_direct3d, dxva2: use the same D3D devicewm42015-07-034-0/+42
| | | | | Since we still read-back (and don't have hard plans on changing this), this doesn't have much of an advantage.
* dxva2: move device creation codewm42015-07-031-34/+50
| | | | Preparation for the following commit.
* vo_opengl: log some more stuff in verbose modewm42015-07-032-1/+4
|
* vo_opengl: fix "freezes" after seeking with interpolation onwm42015-07-021-1/+5
| | | | | | | | | | | | | | | | | | | | When seeking to a different position, and seeking takes long, the OSD might get redrawn. This means that the VO will receive a request to redraw an old frame using whatever the previous PTS was. This breaks the interpolation logic: the old frame will be added to the queue, and then the next frames (with lower PTS if you seeked backwards) are not drawn as the logic assumes they're past frames. Fix this by using the non-interpolation code path when redrawing after a seek reset, and no "real" frame has been drawn yet. It's a recent regression caused by the redrawing code simplification. The old code simply sent a VOCTRL for redrawing the frame, and the VO had to deal with retaining the old frame on its own. This is a hack as in there's probably a better solution. Fixes #2097.