summaryrefslogtreecommitdiffstats
path: root/video/decode
Commit message (Collapse)AuthorAgeFilesLines
* 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
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are going to be users who have a Mesa installation which do not support 10 bit, but a GPU which can decode to 10 bit. So it's probably better not to hardcode whether it is supported. Introduce a more general way to signal supported formats from renderer to decoder. Obviously this is imperfect, because it still isn't part of proper format negotation (for example, what if there's a vavpp filter, which accepts anything). Still slightly better than before. I don't know any way to probe for vaapi dmabuf/EGL dmabuf support properly (in particular testing specific formats, not just general availability). So we stay with the current approach and try to create and map dummy surfaces on init to probe for support. Overdo it and check all formats that AVHWFramesConstraints reports, instead of only NV12 and P010 surfaces. Since we can support unknown formats now, add explicitly checks to the EGL/dmabuf mapper code to reject unsupported formats. I also noticed that libavutil signals support for RGB0/BGR0, but couldn't get it to work. Remove the DRM formats that are unused/didn't work the way I tried to use them. With this, 10 bit decoding + rendering should work, provided you have a capable CPU and a patched Mesa. The required Mesa patch adds support for the R16 and GR32 formats. It was sent by a Kodi developer to the Mesa developer mailing list and was not accepted yet.
* vaapi: always create AVHWDeviceContext on initwm42017-01-131-13/+2
| | | | | | For convenience. Since we still have code that works even if creating a AVHWDeviceContext fails, failure is ignored. (Although currently, it succeeds creation even with the stale/abandoned vdpau wrapper driver.)
* vaapi: fix typowm42017-01-121-1/+1
|
* vaapi: explicitly reject 10 bit surfaces outside of copy modewm42017-01-121-0/+7
| | | | | | | | Rendering support in Mesa probably doesn't exist yet. In theory it might be possible to use VPP to convert the surfaces to 8 bit (like we do it with dxva2/d3d11va as ANGLE doesn't support rendering 10 bit surface either), but that too would require explicit mechanisms. This can't be implemented either until I have a GPU with actual support.
* vaapi: handle image copying for vaapi-copy in common codewm42017-01-123-13/+16
| | | | | | | | | | | | | | Other hwdecs will also be able to use this (as soon as they are switched to use AVHWFramesContext). As an additional feature, failing to copy back the frame counts as hardware decoding failure and can trigger fallback. This can be done easily now, because it needs no way to communicate this from the hwaccel glue code to the common code. The old code is still required for the old decode API, until we either drop or rewrite it. vo_vaapi.c's OSD code (fuck...) also uses these surface functions to a higher degree.
* vd_lavc, mp_image: remove code duplication for AVFrame<->mp_imagewm42017-01-121-27/+5
| | | | | | | | | Mostly affects conversion of the colorimetric parameters. Not changing AV_FRAME_DATA_MASTERING_DISPLAY_METADATA handling - that's too messy, as decoders typically output it for keyframes only, and would require weird caching that can't even be done on the level of the frame rewrapping functions.
* vaapi: properly set hw_subfmt field with new decode APIwm42017-01-122-7/+6
| | | | | | | | This fixes direct rendering with hwdec_vaegl.c. The code duplication between update_image_params() and mp_image_copy_fields_from_av_frame() is quite annoying, bit will have to be resolved in another commit.
* vaapi: set our own context in AVHWFramesContext not AVHWDeviceContextwm42017-01-121-3/+3
| | | | | | AVHWDeviceContext.user_opaque is reserved to libavutil under certain circumstances, while AVHWFramesContext.user_opaque is truly free for use by us. It's slightly simpler too.
* vaapi: support new libavcodec vaapi APIwm42017-01-113-1/+243
| | | | | | | | | | | | | | | | | The old API is deprecated, and libavcodec prints a warning at runtime. The new API is a bit nicer and does many things for you, such as managing the underlying hwaccel decoder. libavutil also provides code for managing surfaces (we use their surface pool). The new code does not contain any code from the original MPlayer VAAPI patch (that was used as base for some of the vaapi code in mpv). Thus the new code is LGPL. The new API actually does not add any visible symbols, so the only way to detect it is a version check. Of course, the versions overlap between FFmpeg and Libav, which requires additional care. The new API did not get merged into FFmpeg yet, so there's no check for FFmpeg.
* vaapi: move standalone display creation code to common codewm42017-01-111-136/+9
| | | | Preparation for the following commits.
* vaapi: rename vaapi.c to vaapi_old.cwm42017-01-111-0/+0
| | | | | vaapi.c will be reintroduced with the new code using the new libavcodec vaapi API.
* video: share hwdec extra surface count between backendswm42017-01-113-2/+9
| | | | It's a quite important and fragile magic number.
* vd_lavc: inline a functionwm42017-01-111-45/+37
| | | | | There's only 1 caller now, so having it as separate function doesn't make too much sense, and makes the code less readable, if anything.
* video: make decoder EOF reporting explicitwm42017-01-113-51/+38
| | | | | | | | | | | | | | | This is simpler and more robust, especially for the hwdec fallback case. The most annoying issue is that C doesn't support multiple return values (or sum types), so the decode call gets all awkward. The hwdec fallback case does not need to try to produce some output after the fallback anymore. Instead, it can use the normal "replay" code path. We invert the "eof" bool that vd_lavc.c used internally. The receive_frame decoder API returns the inverse of EOF, because returning "true" from the decode function if EOF was reached feels awkward.
* vd_lavc: fix some leaks and a discarded frame on hwdec fallbackwm42017-01-111-1/+6
| | | | Wasn't a problem in most normal scenarios.
* vd_lavc: move end-of-probing code out of user notification if conditionwm42017-01-111-1/+3
| | | | | | Usually they happen at the same time, but conflating them is still a bit unclean and could possibly cause problems in the future. It's also really unnecessary.
* vd_lavc: return proper error codes from get_buffer2 callbackwm42017-01-111-2/+2
| | | | -1 is essentially random and usually the same as AVERROR(EPERM).
* vd_lavc: complicated improved fallback behavior for --hwdec=cudawm42017-01-102-16/+65
| | | | | | | | | | | | | The ffmpeg cuda wrappers need more than 1 packet for determining whether hw decoding will work. So do something complicated and keep up to 32 packets when trying to do hw decoding, and replay the packets on the software decoder if it doesn't work. This code was written in a delirious state, testing for regressions and determining whether this is worth the trouble will follow later. All mpv git users are alpha testers as of this moment. Fixes #3914.
* video: restructure decode loopwm42017-01-104-95/+138
| | | | Basically change everything. Why does the code get larger? No idea.
* player: change aspects of cover art handlingwm42017-01-102-18/+0
| | | | | | | | | | | | | | | | | | | | | | | | Cover art handling is a disgusting hack that causes a mess in all components. And this will stay this way. This is the Xth time I've changed cover art handling, and that will probably also continue. But change the code such that cover art is injected into the demux packet stream, instead of having an explicit special case it in the decoder glue code. (This is somewhat more similar to the cover art hack in libavformat.) To avoid that the over art picture is decoded again on each seek, we need some additional "caching" in player/video.c. Decoding it after each seek would work as well, but since cover art pictures can be pretty huge, it's probably ok to invest some lines of code into caching it. One weird thing is that the cover art packet will remain queued after seeks, but that is probably not an issue. In exchange, we can drop the dec_video.c code, which is pretty convenient for one of the following commits. This code duplicates a bunch of lower-level decode calls and does icky messing with this weird state stuff, so I'm glad it goes away.
* Prefix libavcodec CODEC_FLAG_ constants with AV_wm42016-12-291-3/+3
| | | | The unprefixed versions are silently deprecated.
* options: deprecate codec family selection in --vd/--adwm4