summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
* win32: replace libuuid.a usage with initguid.hJames Ross-Gowan2016-05-014-1/+5
| | | | | | | | | | | | | | | Including initguid.h at the top of a file that uses references to GUIDs causes the GUIDs to be declared globally with __declspec(selectany). The 'selectany' attribute tells the linker to consolidate multiple definitions of each GUID, which would be great except that, in Cygwin and MinGW GCC 6.1, this method of linking makes the GUIDs conflict with the ones declared in libuuid.a. Since initguid.h obsoletes libuuid.a in modern compilers that support __declspec(selectany), add initguid.h to all files that use GUIDs and remove libuuid.a from the build. Fixes #3097
* os x: handle multiple dropped files on the windowNyx0uf2016-04-301-2/+7
| | | | | | Should fix #3076 (partially). Signed-off-by: wm4 <wm4@nowhere>
* w32_common: respect --fit-border on size checkmaniak13492016-04-301-4/+20
| | | | | | Fit whole window or just a client area in accord with value of --fit-border option. Fixes #2935.
* w32_common: fix size calculations for window resizemaniak13492016-04-301-3/+3
| | | | | | | Substraction of 1 is not necessary due to .right and .bottom values of RECT struct describing a point one pixel outside of the rectangle. Fixes #2935. (2.b)
* d3d11va: fix invalid deref on decoder init failureKevin Mitchell2016-04-291-1/+1
| | | | fixes #3092
* d3d11va, dxva2: return the format struct directlywm42016-04-294-16/+13
| | | | Slight simplification, IMHO.
* d3d11va, dxva2: simplify decoder selectionwm42016-04-294-67/+58
| | | | | | | | In particular, this moves the depth test to common code. Should be functionally equivalent, except that for DXVA2, the IDirectXVideoDecoderService_GetDecoderRenderTargets API is called more often potentially.
* video: add IMGFMT_P010 aliaswm42016-04-293-2/+8
| | | | Gets rid of some silliness, and might be useful in the future.
* vo_opengl: fix build with GLES3 headerswm42016-04-271-0/+2
| | | | Legacy desktop GL only symbols. Broken by the previous commit.
* vo_opengl: support GL_EXT_texture_norm16 on GLESwm42016-04-273-6/+12
| | | | | | | | | | | | | | | This gives us 16 bit fixed-point integer texture formats, including ability to sample from them with linear filtering, and using them as FBO attachments. The integer texture format path is still there for the sake of ANGLE, which does not support GL_EXT_texture_norm16 yet. The change to pass_dither() is needed, because the code path using GL_R16 for the dither texture relies on glTexImage2D being able to convert from GL_FLOAT to GL_R16. GLES does not allow this. This could be trivially fixed by doing the conversion ourselves, but I'm too lazy to do this now.
* vo_opengl: always use sized internal formatswm42016-04-271-8/+8
| | | | | This shouldn't make much of a difference, but should make the following commit simpler.
* vo_opengl: d3d11egl: minor simplificationwm42016-04-271-5/+1
| | | | | This should be ok. eglBindTexImage() just associates the texture, and does not make a copy (not even a conceptual one).
* vo_opengl: d3d11egl: print warning on unsupported colorspaceswm42016-04-271-0/+11
| | | | | Not much we can do about. If there are many complaints, a mechanism to automatically disable interop in such cases could be added.
* d3d11va: store texture/subindex in IMGFMT_D3D11VA plane pointerswm42016-04-274-140/+72
| | | | | | | | | Basically this gets rid of the need for the accessors in d3d11va.h, and the code can be cleaned up a little bit. Note that libavcodec only defines a ID3D11VideoDecoderOutputView pointer in the last plane pointers, but it tolerates/passes through the other plane pointers we set.
* vd_lavc: adjust D3D11VA autoprobe orderwm42016-04-271-1/+3
| | | | | | We want to prefer d3d11va over dxva2 anything. But since dxva2 copyback is more efficient than d3d11va's currently, d3d11va-copy should come last.
* vo_opengl: D3D11VA + ANGLE interopwm42016-04-279-2/+468
| | | | | | | | | | | | | | | | | | | This uses ID3D11VideoProcessor to convert the video to a RGBA surface, which is then bound to ANGLE. Currently ANGLE does not provide any way to bind nv12 surfaces directly, so this will have to do. ID3D11VideoContext1 would give us slightly more control about the colorspace conversion, though it's still not good, and not available in MinGW headers yet. The video processor is created lazily, because we need to have the coded frame size, of which AVFrame and mp_image have no concept of. Doing the creation lazily is less of a pain than somehow hacking the coded frame size into mp_image. I'm not really sure how ID3D11VideoProcessorInputView is supposed to work. We recreate it on every frame, which is simple and hopefully doesn't affect performance.
* hwdec: remove numbers from enumwm42016-04-271-10/+10
| | | | | | | They don't actually mean anything. Just HWDEC_NONE should remain 0, because it's the default init value for structs etc.
* vo_opengl: print error if opengl hwdec interop failswm42016-04-271-0/+2
|
* vd_lavc: hack against videotoolbox crash on failurewm42016-04-261-1/+3
| | | | | I guess this won't ever be fixed properly in FFmpeg. Too hairy, and the alternative (using VideoToolbox as "full decoder") is too attractive.
* vo_rpi: rename mutex/cond variableswm42016-04-261-17/+17
| | | | They're now used for the TV callback too, not just vsync.
* vo_rpi: wait for vsync with a timeoutwm42016-04-261-2/+6
| | | | | | Sucks, but better than freezing forever given the (to me) unpredictable RPI behavior. This will be good enough to drop out of vsync timing mode, or to abort playback.
* vo_rpi: attempt to survive display mode changeswm42016-04-261-38/+90
| | | | | | | | | | | | Recreate all dispmanx objects after mode changes signalled by the TV callback. This is needed since dispmanx objects are marked as invalid and cease working. One important point is that the vsync callbacks will stop coming when this happens, so restoring the callback is important. Note that the MMAL renderer itself does not get trashed by the firmware on such events, but we completely reconfigure it anyway when it happens.
* vp_rpi: fix indentationwm42016-04-261-10/+8
| | | | | This also moves the p->background check into the top if (the code effectively didn't do anything when this false).
* vd_lavc: simplify some unneeded ifdefferywm42016-04-251-8/+2
| | | | These were for ancient libavcodec versions.
* vd_lavc: make image_format hwdec field optionalwm42016-04-251-26/+24
| | | | | | | For Mediacodec in particular we don't care about the format. It can just decode to whatever it wants. The only case we would care about is it not returning an opaque format if we don't have proper interop, but libavcodec always returns non-opaque formats by default.
* vd_lavc: simplify RPI and Mediacodec wrapperswm42016-04-253-141/+12
| | | | | | | | | | | | Use the recently added lavc_suffix mechanism to select the wrapper decoder. With all hwdec callbacks being optional, and RPI/Mediacodec having only dummy callbacks, all the callbacks can be removed as well. The result is that the vd_lavc_hwdec struct for both of them is tiny. It's better to move them to vd_lavc.c directly, because they are so trivial and small.
* vd_lavc: make all hwdec callbacks optionalwm42016-04-251-2/+2
|
* vd_lavc: set AVCodecContext.time_base to forced time basewm42016-04-251-0/+3
| | | | | This is a bit sketchy, as there isn't a truly standard way to communicate the timebase.
* vd_lavc: better hwdec wrapper decoder selectionwm42016-04-252-1/+66
| | | | | | | | | | | | | | | | This is intended for cases when --hwdec needs to override the decoder implementation in use, like for example on the RPI. It does two things: 1. Allow the hwdec to indicate a decoder suffix. libavcodec by convention adds a suffix to all wrapper decoders, and here we start relying on it. While not necessarily the best idea, it's the only thing we got. libavcodec's hwaccel list is useless, because it only has the codec ID, not the associated decoder's name. 2. Make --hwdec=auto work properly. It shouldn't fail anymore, and hwdec probing should reliably work, even if a different decoder is selected with --vd. The semantics of --hwdec should dictate that it overrides the default decoder.
* vd_lavc: allow process_image() to return NULLwm42016-04-251-1/+1
| | | | In case of errors or whatever.
* mp_image: allow passing NULL to mp_image_new_custom_ref()wm42016-04-255-9/+7
| | | | | | | A minor simplification. Most callers don't need this, and there's no good reason why the caller should provide an "initializer" like this. (This function calls mp_image_new_dummy_ref(), which has no reason for an initializer either.)
* vd_lavc: fix hwdec fallback if hwdec pre-initialization failswm42016-04-221-7/+7
| | | | Damn.
* vo_opengl: always reset some GL state when leaving rendererwm42016-04-221-5/+6
| | | | | | The active texture and some pixelstore parameters are now always reset to defaults when entering and leaving the renderer. Could be important for libmpv.
* d3dva: move Intel_H264_NoFGT_ClearVideo to lower priorityKevin Mitchell2016-04-181-1/+1
| | | | | | This seems to cause problems, so only use it if H264_E is not available. fixes #3059
* dxva2: fix missing newline in error messageKevin Mitchell2016-04-181-1/+1
|
* d3dva: include selected decoder and format in verbose outputKevin Mitchell2016-04-172-0/+7
|
* vo_opengl: fix an outdated commentwm42016-04-161-3/+1
| | | | This wasn't updated over multiple iterations.
* vo_lavc: fix build on Libavwm42016-04-151-2/+1
| | | | | OF COURSE Libav doesn't have AV_PICTURE_TYPE_NONE. Why the fuck would it?
* mp_image: make mp_image_copy_fields_* privatewm42016-04-152-8/+4
| | | | | Future code should always use mp_image_{to,from}_av_frame(). Everything else is way too messy and fragile.
* vo_lavc: unsupport deprecated AVFMT_RAWPICTUREwm42016-04-151-23/+12
| | | | | | | | As of ffmpeg git master, only the libavdevice decklink wrapper supports this. Everything else has dropped support. You're now supposed to use AV_CODEC_ID_WRAPPED_AVFRAME, which works a bit differently. Normal AVFrames should still work for these encoders.
* vo_lavc: send refcounted AVFrame to encoderwm42016-04-151-4/+4
| | | | | | This potentially makes it more efficient, and actually makes it simpler. Yes, AV_PICTURE_TYPE_NONE is the default for pict_type.
* mp_image: add mp_image_to_av_frame()wm42016-04-152-6/+10
| | | | | What mp_image_to_av_frame_and_unref() should have been. (The _unref variant is still useful though.)
* mp_image: simplify mp_image_steal_data()wm42016-04-151-17/+7
| | | | Why was this so complex.
* mp_image: pass through AVHWFramesContextwm42016-04-152-4/+22
| | | | In both directions.
* lcms: include math.hwm42016-04-151-0/+1
| | | | Fixes #3053.
* vo_opengl: rpi: don't include x11 header filewm42016-04-151-1/+0
| | | | Copy & paste bug.
* vo_opengl: simplify and improve up scale=oversampleNiklas Haas2016-04-121-21/+5
| | | | | | | | | Since what we're doing is a linear blend of the four colors, we can just do it for free by using GPU sampling. This requires significantly fewer texture fetches and calculations to compute the final color, making it much more efficient. The code is also much shorter and simpler.
* vf_vavpp: reindentwm42016-04-111-8/+6
|
* vaapi: determine surface format in decoder, not in rendererwm42016-04-115-47/+71
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Until now, we have made the assumption that a driver will use only 1 hardware surface format. the format is dictated by the driver (you don't create surfaces with a specific format - you just pass a rt_format and get a surface that will be in a specific driver-chosen format). In particular, the renderer created a dummy surface to probe the format, and hoped the decoder would produce the same format. Due to a driver bug this required a workaround to actually get the same format as the driver did. Change this so that the format is determined in the decoder. The format is then passed down as hw_subfmt, which allows the renderer to configure itself with the correct format. If the hardware surface changes its format midstream, the renderer can be reconfigured using the normal mechanisms. This calls va_surface_init_subformat() each time after the decoder returns a surface. Since libavcodec/AVFrame has no concept of sub- formats, this is unavoidable. It creates and destroys a derived VAImage, but this shouldn't have any bad performance effects (at least I didn't notice any measurable effects). Note that vaDeriveImage() failures are silently ignored as some drivers (the vdpau wrapper) support neither vaDeriveImage, nor EGL interop. In addition, we still probe whether we can map an image in the EGL interop code. This is important as it's the only way to determine whether EGL interop is supported at all. With respect to the driver bug mentioned above, it doesn't matter which format the test surface has. In vf_vavpp, also remove the rt_format guessing business. I think the existing logic was a bit meaningless anyway. It's not even a given that vavpp produces the same rt_format for output.
* encode_lavc: Migrate to codecpar API.Rudolf Polzer2016-04-111-31/+35
|
* aspect: rework --video-unscaledNiklas Haas2016-04-101-22/+12
| | | | | | | | | | | | | | | | | | | In the past, --video-unscaled also disabled zooming and aspect ratio corrections. But this didn't make much sense in terms of being a useful option. The new behavior just sets the initial video size to be unscaled, but it's still affected by zoom commands and aspect ratio corrections. To get the old behavior back, --video-aspect=0 --video-zoom=0 need to be added as well (in the general case). Most of the time it should not make a difference though. Also, there seems to have been some additional dst_rect clamping code inside src_dst_split_scaling that didn't seem to either be necessary nor ever get triggered. (The code immediately above it already makes sure to crop the video if it's larger than the dst_rect) No idea why it was there, but I just removed it.
* aspect: remove useless debug messageswm42016-04-101-10/+2
| | | | Never needed them. This makes the code slightly more readable.
* vo_opengl: improve rotation handling (again)wm42016-04-082-44/+47
| | | | | | | | | | | | | | | | | Apply basic transformations like rotation by 90° and mirroring when sampling from the source textures. The original idea was making this part of img_tex.transform, but this didn't work: lots of code plays tricks on the transform, so manipulating it is not necessarily transparent, especially when width/height are switched. So add a new pre_transform field, which is strictly applied before the normal transform. This fixes most glitches involved with rotating the image. Cropping and rotation are now weirdly separated, even though they could be done in the same step. I think this is not much of a problem, and has the advantage that changing panscan does not trigger FBO reallocations (I think...).
* vo_opengl: log if glGetString(GL_VERSION) returns NULLwm42016-04-081-1/+3
| | | | | | Typically happens with some implementations if no context is currrent, or is otherwise broken. This is particularly relevant to the opengl_cb API, because the API user will have no other indication what went wrong.
* d3d: fix Windows buildwm42016-04-071-2/+2
| | | | | | Commit f009d16f accidentally broke it. Thanks to RiCON for noticing and testing.
* vo_opengl: videotoolbox: use kCVPixelBufferLock_ReadOnly for screenshotswm42016-04-071-7/+8
| | | | Why not.
* videotoolbox: change how videotoolbox format is managedwm42016-04-074-6/+36
| | | | | | | | | | | | | | | | | | | | | | | The underlying intention of this code is to make changing --videotoolbox-format at runtime work. For this reason, the format can't just be statically setup, but must be read from the option at runtime. This means the format is not fixed anymore, and we have to make sure the renderer is property reinitialized if the format changes. There is currently no way to trigger reinit on this level, which is why the mp_image_params.hw_subfmt field was introduced. One sketchy thing remains: normally, the renderer is supposed to be involved with VO format negotiation, which would ensure that the VO can take the format at all. Since the hw_subfmt is not part of this format negotiation, it's implied the get_vt_fmt() callback only returns formats supported by the renderer. This is not necessarily clear because vo_opengl checks this with converted_imgfmt separately. None of this matters in practice though, because we know all formats are always supported. (This still requires somehow triggering decoder reinit to make the change effective.)
* mp_image: introduce a hw_subfmt fieldwm42016-04-072-0/+8
| | | | | | | | | | | For hwaccel formats, mp_image will merely point to a hardware surface handle. In these cases, the mp_image_params.imgfmt field describes the format insufficiently, because it mostly only describes the type of the hardware format, not its underlying format. Introduce hw_subfmt to describe the underlying format. It makes sense to use it with most hwaccels, though for now it will be used with the following commit only.
* vd_lavc: let hardware decoder request delaying frames explicitlywm42016-04-075-4/+9
| | | | | | | | | | Until now, the presence of the process_image() callback was used to set a delay queue with a hardcoded size. Change this to a vd_lavc_hwdec field instead, so the decoder can explicitly set this if it's really needed. Do this so process_image() can be used in the VideoToolbox glue code for something entirely unrelated.
* vd_lavc: fix codec vs. decoder confusionwm42016-04-0710-31/+32
| | | | | | | | | | Some functions which expected a codec name (i.e. the name of the video format itself) were passed a decoder name. Most "native" libavcodec decoders have the same name as the codec, so this was never an issue. This should mean that e.g. using "--vd=lavc:h264_mmal --hwdec=mmal" should now actually enable native surface mode (instead of doing copy- back).
* vo: don't reset vsync statistics on seeks etc.wm42016-04-061-9/+14
| | | | | | | | | | | | | | | | | | The sync-by-display mode relies on using the vsync statistics for timing. As a consequence discontinuities must be handled somehow. Until now we have done this by completely resetting these statistics. This can be somewhat annoying, especially if the GL driver's vsync timing is not ideal. So after e.g. a seek it could take a second until it locked back to the proper values. Change it not to reset all statistics. Some state obviously has to be reset, because it's a discontinuity. To make it worse, the driver's vsync behavior will also change on such discontinuities. To compensate, we discard the timings for the first 2 vsyncs after each discontinuity (via num_successive_vsyncs). This is probably not fully ideal, and num_total_vsync_samples handling in particular becomes a bit questionable.
* vo_opengl: fix build breakagewm42016-04-061-1/+1
|
* vo_opengl: minor simplificationwm42016-04-051-3/+2
| | | | It's the same functionally.
* vo_opengl: fix nnedi + rectangle textureswm42016-04-053-4/+4
|