summaryrefslogtreecommitdiffstats
path: root/video/decode
Commit message (Collapse)AuthorAgeFilesLines
* 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-042-43/+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: fix behavior with deprecated FFmpeg J pixel formatswm42017-07-042-0/+4
| | | | | | | | They have been deprecated for a decade, yet you're forced to explicitly deal with them at every step, or they will break your shit. FFmpeg insists on keeping them, because libavfilter is too stupid to deal with color ranges properly. Ridiculous.
* d3d: UWP support for D3D11VAwm42017-06-303-12/+19
| | | | | | | For some braindead reason, Microsoft decided to prevent you from dynamically loading system libraries. This makes portability harder. And we're talking about portability between Microsoft OSes!
* d3d: make DXVA2 support optionalwm42017-06-302-1/+9
| | | | | | | | | | | | 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-183-18/+36
| | | | | | | | | | | | | 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.
* dec_video: change license to LGPL (almost)wm42017-06-182-1/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "Almost" because this might contain copyright by michael, who agreed with LGPL, but only once the core is LGPL. This is preparation for that to happen. Apart from that, the usual remarks apply. In particular, dec_video.c started out quite chaotic with no modularization, but was later basically gutted, and in general rewritten a bunch of times. Not going to give a history lesson. Special attention needs to be given to 3 patches by cehosos, who did not agree to the relicensing: 240b743ebdf: --field-dominance e32cbbf7dc3: reinit VO if aspect ratio changes 306f6243fdf: use container aspect if codec aspect unset (?) The first patch is pretty clearly still in the current code, and needs to be disabled for LGPL. The functionality of the second patch is still active, but implemented completely different, and as part of general frame parameter changes (at the time of the patch, MPlayer already reinitialized the VO on frame size and pixel format changes - all this was merged into a single check for changing image parameters). The third patch makes me a bit more uncomfortable. It appears the code was moved to dec_video.c in de68b8f23c8c, and further changed in 82f0d373, 0a0bb905, and bf13bd0d. You could claim that cehoyos' copyright still sticks. Fortunately, we implement alternative aspect detection, which is simpler and probably preferable, and which arguably contains none of the original code and logic, and thus should be fully safe. While I don't know if cehoyos' copyright actually still applies, I'm more comfortable with making the code GPL-only for now. Also change the default to use the (in future) plain LGPL code, and deprecate the one associated with the GPL code, so we can eventually remove the GPL code. But it's also possible we decide that the copyright doesn't apply, and undo the deprecation and GPL guards. I expect that users won't notice anything. If you ask me, the old aspect method was probably an accidental bug instead of intentional behavior. Although, the new aspect method was broken too, so I had to fix it.
* vd, vd_lavc: change license to LGPL (almost)wm42017-06-152-8/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | 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-086-13/+381
| | | | | | 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-242-0/+64
| | | | | | | | | | | 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-053-3/+27
| | | | See FFmpeg commit c0f17a905f3588bf61ba6d86a83c6835d431ed3d.
* d3d: fix build with Libavwm42017-05-042-0/+2
| | | | Apparently it has been broken since forever?
* d3d11: change mp_image plane pointer semanticswm42017-05-042-8/+8
| | | | | | | | Until now, the texture pointer was stored in plane 1, and the texture array index was in plane 2. Move this down to plane 0 and plane 1. This is to align it to the new WIP D3D11 decoding API in Libav, where we decided that there is no reason to avoid setting plane 0, and that it would be less weird to start at plane 0.
* 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-032-7/+18
| | | | | | | | | | | | 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 clashing external declarations.
* video: drop vaapi/vdpau hw decoding support with FFmpeg 3.2wm42017-04-233-597/+3
| | | | | | | | | | This drops support for the old libavcodec APIs. Now FFmpeg 3.3 or FFmpeg git is required. Libav has no release with the new APIs yet, so for Libav git as of a few weeks or months ago or so is required if you want to use Libav. Not much actually changes in hwdec_vaegl.c - some code is removed, but the reindentation inflates the diff.
* vd_lavc: fix return value in receive_frame()wm42017-04-071-1/+1
| | | | | Pointed out by uau. Not sure why gcc doesn't warn (it uses ((void*)0) for NULL).
* vd_lavc: fix potential build failure with vaapiwm42017-03-231-1/+1
| | | | | | | If vaapi was found, but neither the old or new libavcodec vaapi hwaccel API, then HAVE_VAAPI_HWACCEL will be defined, but not _OLD or _NEW. The HAVE_VAAPI_HWACCEL define pretty much exists only for acrobatics with our own waf dependency checker helper code.
* vdpau: support new vdpau libavcodec decode APIwm42017-03-231-3/+41
| | | | | | | | | | | | | | | | | | | The new API works like the new vaapi API, using generic hwaccel support. One minor detail is the error message that will be printed if using non-4:2:0 surfaces (which as far as I can tell is completely broken in the nVidia drivers and thus not supported by mpv). The HEVC warning (which is completely broken in the nVidia drivers but should work with Mesa) had to be added to the generic hwaccel code. This also trashes display preemption recovery. Fuck that. It never really worked. If someone complains, I might attempt to add it back somehow. This is the 4th iteration of the libavcodec vdpau API (after the separate decoder API, the manual hwaccel API, and the automatic vdpau hwaccel API). Fortunately, further iterations will be generic, and not require much vdpau-specific changes (if any at all).
* vdpau: warn on HEVC due to completely broken nVidia driverswm42017-03-141-4/+7
| | | | | | I guess that's the full extent I still care about nVidia's broken garbage. In theory, we could always force the video mixer (which is the only method getting the video data that works), but why bother.
* vd_lavc: disable videotoolbox hack with newer ffmpeg versionswm42017-03-071-2/+5
| | | | | The hack becomes unnecessary with newer versions, but it's still needed for older ones.
* hw_videotoolbox: allow using native decoder output formatwm42017-03-021-2/+8
| | | | | | | Depends on FFmpeg commit ade7c1a2326e2bb9b. It has yet to show whether it actually does what it should. Probably doesn't.
* vd_lavc: log pixel format requested from decoderwm42017-03-011-8/+18
| | | | | | I find it slightly helpful in some situations. Also change the code to have a single exit path to make this easier.
* decode: fix extra surface countwm42017-02-274-5/+4
| | | | | | | | | | | | FFmpeg could crash with vaapi (new) and --vo=opengl + interpolation. It seems the actual surface count the old vaapi code uses (and which usually never exceeded the preallocated amount) was higher than what was used for the new vaapi code, so just correct that. The d3d helpers also had weird code that bumped the real pool size, fix them as well. Why this would result in an assertion failure instead of a proper error, who knows.
* dec_video, dec_audio: remove redundant NULL-checkswm42017-02-201-2/+1
| | | | OK, they're redundant. Now stop wasting my time, coverity.
* Fix two typoswm42017-02-201-1/+1
| | | | They're unrelated. Sue me.
* vd_lavc: increase verbosity if requested hwaccel is not compiledwm42017-02-201-1/+2
| | | | | Well, not like we can detect whether it's missing from libavcodec, but it's still slightly better.
* vd_lavc, vaapi: move hw device creation to generic codewm42017-02-204-155/+84
| | | | | | | | hw_vaapi.c didn't do much interesting anymore. Other than the function to create a device for decoding with vaapi-copy, everything can be done by generic code. Other libavcodec hwaccels are planned to provide the same API as vaapi. It will be possible to drop the other hw_ files in the future. They will use this generic code instead.
* videotoolbox: remove weird format-negotiation between VO and decoderwm42017-02-171-16/+10
| | | | | | | | | | | | | | | | Originally, there was probably some sort of intention to restrict it to formats supported by the interop, or something. But in the end it was overcomplicated nonsense. In the future, we could use mp_hwdec_ctx.supported_formats or other mechanisms to handle this in a better way. mp_hwdec_ctx.ctx is not set to a dummy pointer - hwdec_devices_load() is only used to detect whether to vo_opengl interop is present, and the common hwdec code expects that the .ctx field is not NULL. This also changes videotoolbox-copy to use --videotoolbox-format, instead of the FFmpeg-set default.
* videotoolbox: factor some duplicated codewm42017-02-171-45/+2
| | | | | | | | The code for copying a videotoolbox surface to mp_image was duplicated (with some minor differences - I picked the hw_videotoolbox.c version, because it was "better"). mp_imgfmt_from_cvpixelformat() is somewhat duplicated with the vt_formats[] table, but this will be fixed in a later commit, and moving the function to shared code is preparation.
* vd_lavc: fix inverted error checkwm42017-02-161-1/+1
| | | | Dumb.
* vd_lavc: move most vaapi hwaccel setup code to generic codewm42017-02-163-48/+95
| | | | | Now hw_vaapi.c contains only the device setup, which could probably also be abstracted.
* vd_lavc: remove some leftover vaapi locking infrastructurewm42017-02-162-23/+0
|
* player: add experimental stream recording featurewm42017-02-072-5/+16
| | | | | This is basically a WIP, but it can't remain in a branch forever. A warning is print when using it as it's still a bit "shaky".
* hw_dxva2: create a IDirect3D9Ex devicewm42017-02-021-18/+27
| | | | | | | | | | | This should allow us to create the device in situations when Direct3DCreate9 normally fails, for example if no user is logged in. While the later use-case is not very interesting, I hope it to work in some other situations as well, for example while certain drivers are in exclusive full screen mode. This is available since Windows 7, so I'm removing the old call completely.
* vaapi: improve a commentwm42017-01-281-1/+7
| | | | Try to actually explain what's up with this code.
* vaapi: remove central lock around vaapi API callswm42017-01-282-35/+0
| | | | | | | | The lock was disabled recently. This commit gets rid of the dummied out calls. The main reason for removing it is that there is no apparent need for it anymore, and the new FFmpeg vaapi code does not use or provide such a lock (there are some places which we cannot control and which do vaapi API calls, like frame destructors).
* vd_lavc: allocate 8 ref frames for VP9wm42017-01-261-2/+6
| | | | | | Apparently this is the maximum that can be preserved. There is also something about the decoder being able only to use 3 frames at a time, and I'm assuming these are part of the 8 frames.
* ad_lavc, vd_lavc: move mpv->lavc decoder parameter setup to common codewm42017-01-251-19/+4
| | | | | | | | This can be useful in other contexts. Note that we end up setting AVCodecContext.width/height instead of coded_width/coded_height now. AVCodecParameters can't set coded_width, but this is probably more correct anyway.
* build: replace some FFmpeg API checks with version checkswm42017-01-241-2/+2
| | | | | | The FFmpeg versions we support all have the APIs we were checking for. Only Libav missed them. Simplify this by explicitly checking for FFmpeg in the code, instead of trying to detect the presence of the API.
* vdpau: reject decoding of non-4:2:0wm42017-01-171-0/+5
| | | | | | | | | | | Tried to decode a High 4:2:2 file, since libavcodec code seemed to indicate that it's supported. Well, it decodes to garbage. I couldn't find out why ffmpeg.c actually appears to reject this correctly. The API seems to be fine with, just that the output is garbage. Add a hack for now.
* vd_lavc: always fail decoding immediately if copying hw surface failswm42017-01-171-0/+1
| | | | | | | | | | Successful decoding of a frame resets ctx->hwdec_fail_count to 0 - which us ok, but prevents fallback if it fails if --vd-lavc-software-fallback is set to something higher than 1. Just fail it immediately, since failing here always indicates some real error (or OOM), not e.g. a video parsing error or such, which we try to tolerate via the error counter.
* vdpau: use libavutil for surface allocation during decodingwm42017-01-171-44/+7
| | | | | | | | | | | | | | | | Use the libavutil vdpau frame allocation code instead of our own "old" code. This also uses its code for copying a video surface to normal memory (used by vdpau-copy). Since vdpau doesn't really have an internal pixel format, 4:2:0 can be accessed as both nv12 and yuv420p - and libavutil prefers to report yuv420p. The OpenGL interop has to be adjusted accordingly. Preemption is a potential problem, but it doesn't break it more than it already is. This requires a bug fix to FFmpeg's vdpau code, or vdpau-copy (as well as taking screenshots) will fail. Libav has fixed this bug ages ago.
* vaapi: move AVHWFramesContext setup code to common codewm42017-01-173-52/+63
| | | | | | | | | | In a way it can be reused. For now, sw_format and initial_pool_size determination are still vaapi-specific. I'm hoping this can be eventally moved to libavcodec in some way. Checking the supported_formats array is not really vaapi-specific, and could be moved to the generic code path too, but for now it would make things more complex. hw_cuda.c can't use this, but hw_vdpau.c will in the following commit.
* build: prefix hwaccel decoder wrapper filenames with hw_wm42017-01-177-0/+0
| | | | | | Should have done this a long time ago. d3d.c remains as it is, because it's just a bunch of helper functions.
* cuda: fix 10 bit decodingwm42017-01-161-0/+6
| | | | Messy mess. Unsure whether this will be resolved properly in FFmpeg.
* cuda: fix AVHWFramesContext initializationwm42017-01-161-0/+6
| | | | This was partially done. Strangely it worked anyway.
* vo_opengl: hwdec_cuda: export AVHWDeviceContextwm42017-01-161-25/+4
| | | | So we can use it for filtering later.
* vd_lavc: demote software decoding message to verbose log levelwm42017-01-131-1/+1
| | | | | | | | | | | If hardware decoding is enabled (via --hwdec anything), the player was printing an informational message that software decdoing is used. Basically, this confuses users, because they think there is a problem or such. Just disable the message, it's semi-useless anyway. This was suggested on IRC, after yet another user was asking why this message was shown (with a follow up discussion which CPUs can decode what kind of video codecs).
* vo_opengl, vaapi: properly probe 10 bit rendering supportwm42017-01-131-9/+20
| | | | | | |