summaryrefslogtreecommitdiffstats
path: root/video/decode/vd_lavc.c
Commit message (Collapse)AuthorAgeFilesLines
* video: refactor hw device creation for hwdec copy modeswm42017-12-011-12/+23
| | | | | | | | | | Lots of shit code for nothing. We probably could just use libavutil's code for all of this. But for now go with this, since it tends to prevent stupid terminal messages during probing (libavutil has no mechanism to selectively suppress errors specifically during probing). Ignores the "emulated" API flag (for avoiding vaapi/vdpau wrappers), but it doesn't matter that much for -copy anyway.
* vd_lavc: move entrypoint for hwframes_refinewm42017-12-011-2/+5
| | | | | | | The idea is to get rid of vd_lavc_hwdec, so special functionality like this has to go somewhere else. At this point, hwframes_refine is only needed for d3d11, and it doesn't do much, so for now the new callback has no context. In can be made more fancy if really needed.
* vd_lavc: remove process_image callbackwm42017-12-011-3/+0
| | | | Now unused.
* vo_gpu: make it possible to load multiple hwdec interop driverswm42017-12-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Make the VO<->decoder interface capable of supporting multiple hwdec APIs at once. The main gain is that this simplifies autoprobing a lot. Before this change, it could happen that the VO loaded the "wrong" hwdec API, and the decoder was stuck with the choice (breaking hw decoding). With the change applied, the VO simply loads all available APIs, so autoprobing trickery is left entirely to the decoder. In the past, we were quite careful about not accidentally loading the wrong interop drivers. This was in part to make sure autoprobing works, but also because libva had this obnoxious bug of dumping garbage to stderr when using the API. libva was fixed, so this is not a problem anymore. The --opengl-hwdec-interop option is changed in various ways (again...), and renamed to --gpu-hwdec-interop. It does not have much use anymore, other than debugging. It's notable that the order in the hwdec interop array ra_hwdec_drivers[] still matters if multiple drivers support the same image formats, so the option can explicitly force one, if that should ever be necessary, or more likely, for debugging. One example are the ra_hwdec_d3d11egl and ra_hwdec_d3d11eglrgb drivers, which both support d3d11 input. vo_gpu now always loads the interop lazily by default, but when it does, it loads them all. vo_opengl_cb now always loads them when the GL context handle is initialized. I don't expect that this causes any problems. It's now possible to do things like changing between vdpau and nvdec decoding at runtime. This is also preparation for cleaning up vd_lavc.c hwdec autoprobing. It's another reason why hwdec_devices_request_all() does not take a hwdec type anymore.
* vd_lavc: prefer nvdec over vdpau with --hwdec=autowm42017-11-301-11/+13
| | | | | | | | | | | | | | | | nvdec aka cuvid aka cuda should work much better than vdpau, and support newer codecs (such as vp9), and more advanced surface formats (like 10 bit). This requires moving the d3d hwaccels in the autoprobe order, since on Windows, d3d decoding should be preferred over nvidia proprietary stuff. Users of older drivers will need to force --hwdec=vdpau, since it could happen that the vo_gpu cuda hwdec interop loads (so the vdpau interop is not loaded), but the hwdec itself doesn't work. I expect this does not break AMD (which still needs vdpau for vo_gpu interop, until libva is fixed so it can fully support AMD).
* vd_lavc: restore --hwdec-image-format and d3d11 opaque modewm42017-11-021-0/+2
| | | | | When the ifdeffery for the frame_params API was added, the new code accidentally didn't include this.
* vd_lavc: clean out more hwdec legacy codewm42017-10-311-25/+3
| | | | | | | | All this code used to be required by the old variants of the libavcodec hw decoding APIs. Almost all of that is gone, although the mediacodec API unfortunately still pulls in some old stuff (but not all of it). (mediacodec build/functionality is untested, but should work.)
* vd_lavc: remove more dead legacy codewm42017-10-311-69/+2
| | | | | | | | | | | | | | All of this was dead code and completely unused. get_buffer2_hwdec() is the biggest chunk. One unfortunate thing about it is that, while it was active, it could perform a software fallback much faster, because it didn't have to wait until a full frame is decoded (it actually decoded a full frame, but the current code has to decode many more frames due to the codec delay, because the current code waits until the API returns a decoded frame.) We should probably restore the latter, although since it's an optional optimization, and the current behavior doesn't change with the removal of this code, don't actually do anything about it.
* videotoolbox: use generic code for dummy hwdevice initwm42017-10-311-2/+19
| | | | | And move the remaining code (just 2 struct constant definitions) to vd_lavc.c.
* vd_lavc: remove dead legacy codewm42017-10-311-12/+0
|
* vd_lavc: makre sure required headers are included early enoughwm42017-10-311-1/+0
| | | | Should fix #5062.
* vd_lavc: move display mastering data stuff to mp_imagewm42017-10-301-39/+0
| | | | | | | | | | | This is where it should be. It only wasn't because of an old libavcodec bug, that returned the side data only on every IDR. This required some sort of caching, which is now dropped. (mp_image wouldn't have been able to do this kind of caching, because this code is stateless.) We don't support these old libavcodec versions anymore, which is why this is not needed anymore. Also move initialization of rotation/stereo stuff to dec_video.c.
* Bump libav* API usewm42017-10-301-154/+6
| | | | (Not tested on Windows and OSX.)
* vd_lavc: make --hwdec=nvdec-copy actually workwm42017-10-301-3/+28
| | | | | | | | | | | | This simply didn't work. Unlike cuda-copy, this is a true hwaccel, and obviously we need to provide it a device. Implement this in a relatively generic way, which can probably reused directly by videotoolbox (not doing this yet because it would require testing on OSX). Like with cuda-copy, --cuda-decode-device is ignored. We might be able to provide a more general way to select devices at some later point.
* vd_lavc: remove need for duplicated cuda GL interop backendwm42017-10-301-2/+4
| | | | | | | This is just a dumb consequence of HWDEC_ types somehow being part of both decoder and VO. Obviously, the VO should only care about supporting specific hardware surface types or providing specific device types, but until they are separated, stupid unintuitive mismatches will occur.
* Get rid of deprecated AVFrame accessorswm42017-10-301-1/+1
| | | | | | Fist we were required to use them for ABI compat. reasons (and other BS), now they're deprecated and we're supposed to access them directly again.
* vd_lavc: add support for nvdec hwaccelwm42017-10-281-0/+15
| | | | | | | | See manpage additions. (In ffmpeg-mpv and Libav, this is still called "cuvid". Libav won't work yet, because it has no frame params support yet, but this could get fixed soon.)
* vd_lavc: use avcodec_fill_hw_frames_parameters() APIwm42017-10-271-2/+99
| | | | | | | | This removes the need for codec- and API-specific knowledge in the libavcodec hardware acceleration API user. For mpv, this removes the need for vd_lavc_hwdec.pixfmt_map and a few other things. (For now, we still keep the "old" parts for the sake of supporting older Libav, and FFgarbage.)
* vd_lavc: more aggressive frame dropping for intra only codecswm42017-10-261-5/+14
| | | | | | | | Should speed up seeks. (Unfortunately it's useless for backstepping. Backstepping is like precise seeking, except we're unable to drop frames, as we can't know the previous frame if we drop it.)
* Add DRM_PRIME Format Handling and Display for RockChip MPP decodersLionel CHAZALLON2017-10-231-0/+7
| | | | | | | | | | | This commit allows to use the AV_PIX_FMT_DRM_PRIME newly introduced format in ffmpeg that allows decoders to provide an AVDRMFrameDescriptor struct. That struct holds dmabuf fds and information allowing zerocopy rendering using KMS / DRM Atomic. This has been tested on RockChip ROCK64 device.
* video: properly pass through ICC datawm42017-10-161-6/+0
| | | | | | | | | | | | | | | | | | The same should happen with any other side data that matters to mpv, otherwise filters will drop it. (No, don't try to argue that mpv should use AVFrame. That won't work.) ffmpeg_garbage() is copy&paste from frame_new_side_data() in FFmpeg (roughly feed201849b8f91), because it's not public API. The name reflects my opinion about FFmpeg's API. In mp_image_to_av_frame(), change the too-fragile *new_ref = (struct mp_image){0}; into explicitly zeroing out the fields that are "transferred" to the created AVFrame.
* video: make it possible to always override hardware decoding formatwm42017-10-161-0/+2
| | | | | | | | Mostly an obscure option for testing. But --videotoolbox-format can be deprecated, as it becomes redundant. We rely on the libavutil hwcontext implementation to reject invalid pixfmts, or not to blow up if they are incompatible.
* hwdec: add mediacodec hardware decoder for IMGFMT_MEDIACODEC framesAman Gupta2017-10-091-0/+2
|
* hwdec: rename mediacodec to mediacodec-copyAman Gupta2017-10-091-9/+2
|
* build: switch preliminary LGPL mode from v3 to v2.1wm42017-10-051-9/+1
| | | | | | | | | | | iive agreed to relicense things that are still in mpv to LGPLv2.1. So change the licenses of the affected files, and rename the configure switch for LGPL mode to --enable-preliminary-lgpl2. (The "preliminary" part will probably be removed from the configure switch soon as well.) Also player/main.c hasn't had GPL parts since a few commits ago.
* vd_lavc: cuda requires setting hw_device_ctxwm42017-09-261-1/+1
| | | | | | This restores cuda/cuvid under Windows. Cuvid is relatively useless under Windows, but this was requested.
* video: remove old videotoolbox supportwm42017-09-261-6/+1
| | | | | Like as in previous commits, you need a very recent FFmpeg (probably git master).
* video: drop old cuda/cuvid hwaccelwm42017-09-261-8/+1
| | | | Just use FFmpeg 3.3 (or whatever it was) to get Cuvid support.
* vd_lavc: revert accidental vaapi changes revertwm42017-09-221-7/+5
| | | | | | | Commit bfa9b628589068 accidentally reverted these (because my editor did not reload the file correctly). Fixes #4904.
* build: add preliminary LGPL modewm42017-09-211-14/+14
| | | | | | | See "Copyright" file for caveats. This changes the remaining "almost LGPL" files to LGPL, because we think that the conditions the author set for these was finally fulfilled.
* Revert "vd_lavc: change auto-probe order to prefer cuda over vdpau-copy"wm42017-09-191-7/+5
| | | | | | | | | | | This reverts commit 96462040ec79b353457b64949f96fad30bd6e988. I guess the autoprobing is still too primitive to handle this well. What it really should be trying is initializing the wrapper decoder, and if that doesn't work, try another method. This is complicated by hwaccels initializing in a delayed way, so there is no easy solution yet. Probably fixes #4865.
* vd_lavc: change auto-probe order to prefer cuda over vdpau-copywm42017-08-301-5/+7
| | | | | This aims at making --opengl-hwdec-interop=cuda --hwdec=yes select the correct decoding mode: cuda instead of vdpau-copy.
* vd_lavc: work around some more idiotic FFmpeg nonsensewm42017-08-241-0/+4
| | | | | | Like in commit bd356333c713, but for the other hwaccels as well. Fixes #4794.
* vd_lavc: fix mid-stream hwdec fallbackwm42017-08-231-0/+3
| | | | | | Not resetting hwdec_request_reinit caused it to flush on every packet, which not only caused it to fail triggering the actual fallback, and let it never decode a new frame, but also to get stuck on EOF.
* vd_lavc: fix device leak with copy-mode hwaccelswm42017-08-091-2/+3
| | | | | | | | | | | | Apparently this was broken by the "ctx->hwdec" check in the if condition guarding the destroy call, and "ctx->hwdec = NULL;" was moved up earlier, making this always dead code. This should probably be refcounted or so, although that could make it worse as well. For now, add a flag whether the device should be destroyed. Fixes #4735.
* vd_lavc: decode embedded ICC profilesNiklas Haas2017-08-031-0/+6
| | | | | | | | | Since these need to be refcounted, we throw them directly into struct mp_image instead of being part of mp_colorspace. Even though they would semantically make more sense in mp_colorspace, having them there is really awkward because mp_colorspace is passed around and stored a lot, and this way their lifetime is exactly tied to the lifetime of the mp_image associated with it.
* vo_opengl: add direct rendering supportwm42017-07-241-0/+98
| | | | | | | | | | | | | | | | | | | | Can be enabled via --vd-lavc-dr=yes. See manpage additions for what it does. This reminds of the MPlayer -dr flag, but the implementation is completely different. It's the same basic concept: letting the decoder render into a GPU buffer to avoid a copy. Unlike MPlayer, this doesn't try to go through filters (libavfilter doesn't support this anyway). Unless a filter can work in-place, DR will be silently disabled. MPlayer had very complex semantics about buffer types and management (which apparently nobody ever understood) and weird restrictions that mostly limited it to mpeg2 style codecs. The mpv code does not do any of this, and just lets the decoder allocate an arbitrary number of untyped images. (No MPlayer code was used.) Parts of the code based on work by atomnuker (starting point for the generic code) and haasn (some GL definitions, some basic PBO code, and correct fencing).
* vd_lavc: fix crashes with old hwaccelswm42017-07-101-7/+5
| | | | | | | | | | | | | | Commit d5702d3b95 messed up the order of destruction of the elements: it destroyed the avctx before the hwaccel uninit, even though the hwaccel uninit could access avctx. This could happen with some old hwaccels only, such as D3D ones before the new libavcodec hwaccel API. Fix this by making use of the fact that avcodec_flush_buffers() will uninit the underlying hwaccel. Thus we can be sure avctx is not using any hwaccel objects anymore, and it's safe to uninit the hwaccel. Move the hwdec_dev dstruction code with it, because otherwise we would in theory potentially create some dangling pointers in avctx.
* ad_lavc, vd_lavc, sd_lavc: consistently use avcodec_free_context()wm42017-07-061-5/+1
| | | | | Instead of various ad-hoc ways to achieve the same thing. (The API was added only later.)
* vd_lavc: fix build with old FFmpeg/Libav versionswm42017-07-041-1/+1
| | | | | Seems like AV_HWACCEL_FLAG_IGNORE_LEVEL was introduced much earlier than AVCodecContext.hwaccel_flags.
* vd_lavc: remove unused hwaccel support codewm42017-07-041-37/+1
| | | | Was used by old hwaccel implementations.
* vd_lavc: make --vd-lavc-check-hw-profile=no work for generic hwaccelswm42017-07-041-1/+5
| | | | | | | This sets AV_HWACCEL_FLAG_ALLOW_PROFILE_MISMATCH, which some hwaccels using the new generic API respect. These do profile selection in libavcodec, so it can be controlled only with an external flag, instead of in mpv code like it used to be done.
* d3d: make DXVA2 support optionalwm42017-06-301-0/+3
| | | | | | | | | | | | This partially reverts the change from a longer time ago to always build DXVA2 and D3D11VA together. To make it simpler, we change the following: - building with ANGLE headers is now required to build D3D hwaccels - if DXVA2 is enabled, D3D11VA is still forcibly built - the CLI vo_opengl ANGLE backend is now under --egl-angle-win32 This is done to reduce the dependency mess slightly.
* vd: use ST.2086 / HDR10 MaxCLL in addition to mastering metadataNiklas Haas2017-06-181-16/+21
| | | | | | | | | | | | | MaxCLL is the more authoritative source for the metadata we are interested in. The use of mastering metadata is sort of a hack anyway, since there's no clearly-defined relationship between the mastering peak brightness and the actual content. (Unlike MaxCLL, which is an explicit relationship) Also move the parameter fixing to `fix_image_params` I don't know if the avutil check is strictly necessary but I've included it anyway to be on the safe side.
* video: refactor HDR implementationNiklas Haas2017-06-181-1/+1
| | | | | | | | | | | | | | | List of changes: 1. Kill nom_peak, since it's a pointless non-field that stores nothing of value and is _always_ derived from ref_white anyway. 2. Kill ref_white/--target-brightness, because the only case it really existed for (PQ) actually doesn't need to be this general: According to ITU-R BT.2100, PQ *always* assumes a reference monitor with a white point of 100 cd/m². 3. Improve documentation and comments surrounding this stuff. 4. Clean up some of the code in general. Move stuff where it belongs.
* vd, vd_lavc: change license to LGPL (almost)wm42017-06-151-1/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | iive agreed only to LGPL 3.0+ only. All of his relevant changes are for XvMC, for which mpv completely dropped support back in mplayer2 times. But you could claim that the get_format code represents some residual copyright (everything else added by iive was removed, only get_format still is around in some form). While I doubt that this is relly copyright-relevant, consider it is for now. michael is the original author of vd_lavc.c, so this file can become LGPL only after the core becomes LGPL. cehoyos did not agree with the LGPL relicensing, but all of his code is gone. Some others could not be reached, but their code is gone as well. In particular, vdpau support, which was originally done by Nvidia, had larger impact on vd_lavc.c, but vdpau support was first refactored a few times (for the purpose of modularization) and moved to different files, and then decoding was completely moved to libavcodec. Lastly, assigning the "opaque" field was moved by Gwenole Beauchesne in commit 8e5edec13eab. Agreement is pending (due to copyright apparently owned by the author's employer). So just undo the change, so we don't have to think about whether the change is copyrightable.
* d3d: add support for new libavcodec hwaccel APIwm42017-06-081-1/+4
| | | | | | Unfortunately quite a mess, in particular due to the need to have some compatibility with the old API. (The old API will be supported only in short term.)
* videotoolbox: support new libavcodec APIwm42017-05-241-0/+3
| | | | | | | | | | | The new API has literally no advantages (other than that we can drop mp_vt_download_image and other things later), but it's sort-of uniform with the other hwaccels. "--videotoolbox-format=no" is not supported with the new API, because it doesn't "fit in". Probably could be added later again. The iOS code change is untested (no way to test).
* vd_lavc: check for missing device_ctx refwm42017-05-241-0/+5
| | | | | | It's not really guaranteed that other components always set this (e.g. on subtle errors), so check it explicitly. Although I'm not aware of a failing case.
* demux_raw: drop "mp-rawvideo" usewm42017-05-201-5/+0
| | | | | | This is an old pseudo codec to pass through the pixel format. Setup a suitable AVCodecParameter directly instead, so the "rawvideo" codec can be used.
* vdpau: crappy hack to allow initializing hw decoding after preemptionwm42017-05-191-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If vo_opengl is used, and vo_opengl already created the vdpau interop (for whatever reasons), and then preemption happens, and then you try to enable hw decoding, it failed. The reason was that preemption recovery is not run at any point before libavcodec accesses the vdpau device. The actual impact was that with libmpv + opengl-cb use, hardware decoding was permanently broken after display mode switching (something that caused the display to get preempted at least with older drivers). With mpv CLI, you can for example enable hw decoding during playback, then disable it, VT switch to console, switch back to X, and try to enable hw decoding again. This is mostly because libav* does not deal with preemption, and NVIDIA driver preemption behavior being horrible garbage. In addition to being misdesigned API, the preemption callback is not called before you try to access vdpau API, and then only with _some_ accesses. In summary, the preemption callback was never called, neither before nor after libavcodec tried to init the decoder. So we have to get mp_vdpau_handle_preemption() called before libavcodec accesses it. This in turn will do a dummy API access which usually triggers the preemption callback immediately (with NVIDIA's drivers). In addition, we have to update the AVHWDeviceContext's device. In theory it could change (in practice it usually seems to use handle "0"). Creating a new device would cause chaos, as we don't have a concept of switching the device context on the fly. So we simply update it directly. I'm fairly sure this violates the libav* API, but it's the best we can do.
* cuda: add new way to set cuda context on cuvid codecswm42017-05-051-1/+13
| | | | See FFmpeg commit c0f17a905f3588bf61ba6d86a83c6835d431ed3d.
* vd_lavc: fix build with FFmpeg 3.2wm42017-05-041-1/+6
| | | | | | | | Sigh... The functionality is not actually needed for vdpau, but if the vdpau hwaccel is present, the FFmpeg version is new enough that it includes the field.
* vd_lavc: add support for decoders which use AVCodecContext.hw_device_ctxwm42017-05-031-4/+14
| | | | | | | | | | | | These decoders can select the decoding device with hw_device_ctx, but don't use hw_frames_ctx (at least not in a meaningful way). Currently unused, but intended to be used for cuvid, as soon as it hits ffmpeg git master. Also make the vdpau and vaapi hwaccel definition structs static, as we have removed the old code which would have had clash