summaryrefslogtreecommitdiffstats
path: root/video/decode/vd_lavc.c
Commit message (Collapse)AuthorAgeFilesLines
* 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-201-6/+71
| | | | | | | | 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.
* vd_lavc: fix inverted error checkwm42017-02-161-1/+1
| | | | Dumb.
* vd_lavc: move most vaapi hwaccel setup code to generic codewm42017-02-161-0/+63
| | | | | Now hw_vaapi.c contains only the device setup, which could probably also be abstracted.
* vd_lavc: remove some leftover vaapi locking infrastructurewm42017-02-161-20/+0
|
* 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.
* 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.
* vaapi: move AVHWFramesContext setup code to common codewm42017-01-171-0/+54
| | | | | | | | | | 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.
* 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).
* vaapi: handle image copying for vaapi-copy in common codewm42017-01-121-0/+13
| | | | | | | | | | | | | | 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-121-0/+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: support new libavcodec vaapi APIwm42017-01-111-1/+2
| | | | | | | | | | | | | | | | | 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.
* 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-111-34/+19
| | | | | | | | | | | | | | | 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-101-15/+59
| | | | | | | | | | | | | 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-101-78/+106
| | | | Basically change everything. Why does the code get larger? No idea.
* Prefix libavcodec CODEC_FLAG_ constants with AV_wm42016-12-291-3/+3
| | | | The unprefixed versions are silently deprecated.
* vd_lavc: use AVFrame fields directly instead of AVCodecContextwm42016-12-221-4/+4
| | | | | | | | | Conceptually cleaner, although the API claims this is equivalent. Originally, AVCodecContext fields were used, because not all supported libavcodec/libavutil versions had the AVFrame fields. This is not done for chroma_sample_location - it has no AVFrame field.
* video: use demuxer-signaled duration for last video framewm42016-12-211-0/+5
| | | | | | | | | Helps with gif, probably does unwanted things with other formats. This doesn't handle --end quite correctly, but this could be added later. Fixes #3924.
* ad_lavc, vd_lavc: don't set AVCodecContext.refcounted_frameswm42016-12-181-1/+0
| | | | | This field is (or should be) deprecated, and there's no need to set it with the new API.
* Remove compatibility thingswm42016-12-071-8/+1
| | | | | | Possible with bumped FFmpeg/Libav. These are just the simple cases.
* vdpau: fix hwdec uninitwm42016-11-101-0/+1
| | | | | | | | | | | | This is a bit unintuitiv, but it appears hwdec backends have to unset hwdec_priv manually in their uninit function. Normally with this idiom you'd expect the common code to do this (and maybe even freeing the priv struct). Since other hwdec backends do this quite consistently, just fix vdpau for now. Also add an assert to detect similar bugs sooner. Fixes #3788.
* video: add --hwdec=vdpau-copy modewm42016-10-201-0/+2
| | | | | | | At this point, all other hwaccels provide -copy modes, and vdpau is the exception with not having one. Although there is vf_vdpaurb, it's less convenient in certain situations, and exposes some issues with the filter chain code as well.
* ad_lavc, vd_lavc: fix a recent libavcodec deprecation warningwm42016-10-171-1/+1
| | | | | | | | | | | | | | Both AVFrame.pts and AVFrame.pkt_pts have existed for a long time. Until now, decoders always returned the pts via the pkt_pts field, while the pts field was used for encoding and libavfilter only. Recently, pkt_pts was deprecated, and pts was switched to always carry the pts. This means we have to be careful not to accidentally use the wrong field, depending on the libavcodec version. We have to explicitly check the version numbers. Of course the version numbers are completely idiotic, because idiotically the pkg-config and library names are the same for FFmpeg and Libav, so we have to deal with this explicitly as well.
* vd_lavc: Add hwdec wrapper for crystalhdPhilip Langdale2016-10-151-0/+7
| | | | This hardware decodes to system memory so it only requires a wrapper.
* vd_lavc: log if hw decoding selects a different underlying decoderwm42016-09-301-0/+3
| | | | | Less confusing to see what's going on. I think there were more than one users who got tricked by this, including myself.
* rpi: add --hwdec=rpi-copywm42016-09-301-0/+6
| | | | | | This means it can be used with normal video filters. Might help out with #3604.
* video: handle override video parameters in a better placewm42016-09-201-8/+0
| | | | | | | | This really shouldn't be in vd_lavc.c - move it to dec_video.c, where it also applies aspect overrides. This makes all overrides in one place. The previous commit contains some required changes for resetting the image parameters change detection (i.e. it's not done only on video aspect override changes).
* hwdec_cuda: Rename config variable to be more consistentPhilip Langdale2016-09-161-2/+2
| | | | | | 'cuda-gl' isn't right - you can turn this on without any GL and get some non-zero benefit (with the cuda-copy hwaccel). So 'cuda-hwaccel' seems more consistent with everything else.
* hwdec_cuda: Add trivial cuda-copy wrapperPhilip Langdale2016-09-111-0/+9
| | | | | | | | | The cuvid decoder already knows how to copy back to system memory if NV12 frames are requested, and this will happen if the decoder is used without the hwdec. For convenience, let's add a wrapper hwdec so people don't have to explicitly pick the cuvid decoder if they want this behaviour.
* hwdec/opengl: Add support for CUDA and cuvid/NvDecodePhilip Langdale2016-09-081-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Nvidia's "NvDecode" API (up until recently called "cuvid" is a cross platform, but nvidia proprietary API that exposes their hardware video decoding capabilities. It is analogous to their DXVA or VDPAU support on Windows or Linux but without using platform specific API calls. As a rule, you'd rather use DXVA or VDPAU as these are more mature and well supported APIs, but on Linux, VDPAU is falling behind the hardware capabilities, and there's no sign that nvidia are making the investments to update it. Most concretely, this means that there is no VP8/9 or HEVC Main10 support in VDPAU. On the other hand, NvDecode does export vp8/9 and partial support for HEVC Main10 (more on that below). ffmpeg already has support in the form of the "cuvid" family of decoders. Due to the design of the API, it is best exposed as a full decoder rather than an hwaccel. As such, there are decoders like h264_cuvid, hevc_cuvid, etc. These decoders support two output paths today - in both cases, NV12 frames are returned, either in CUDA device memory or regular system memory. In the case of the system memory path, the decoders can be used as-is in mpv today with a command line like: mpv --vd=lavc:h264_cuvid foobar.mp4 Doing this will take advantage of hardware decoding, but the cost of the memcpy to system memory adds up, especially for high resolution video (4K etc). To avoid that, we need an hwdec that takes advantage of CUDA's OpenGL interop to copy from device memory into OpenGL textures. That is what this change implements. The process is relatively simple as only basic device context aquisition needs to be done by us - the CUDA buffer pool is managed by the decoder - thankfully. The hwdec looks a bit like the vdpau interop one - the hwdec maintains a single set of plane textures and each output frame is repeatedly mapped into these textures to pass on. The frames are always in NV12 format, at least until 10bit output supports emerges. The only slightly interesting part of the copying process is that CUDA works by associating PBOs, so we need to define these for each of the textures. TODO Items: * I need to add a download_image function for screenshots. This would do the same copy to system memory that the decoder's system memory output does. * There are items to investigate on the ffmpeg side. There appears to be a problem with timestamps for some content. Final note: I mentioned HEVC Main10. While there is no 10bit output support, NvDecode can return dithered 8bit NV12 so you can take advantage of the hardware acceleration. This particular mode requires compiling ffmpeg with a modified header (or possibly the CUDA 8 RC) and is not upstream in ffmpeg yet. Usage: You will need to specify vo=opengl and hwdec=cuda. Note that hwdec=auto will probably not work as it will try to use vdpau first. mpv --hwdec=cuda --vo=opengl foobar.mp4 If you want to use filters that require frames in system memory, just use the decoder directly without the hwdec, as documented above.
* vd_lavc: always force milliseconds for MMALwm42016-08-291-0/+5
| | | | | This libavcodec wrapper should rescale the API timestamps to whatever it internally needs, but it doesn't yet. So restore this code.
* vd_lavc, ad_lavc: set pkt_timebase, not time_basewm42016-08-291-1/+4
| | | | | | | | | These are different AVCodecContext fields. pkt_timebase is the correct one for identifying the unit of packet/frame timestamps when decoding, while time_base is for encoding. Some decoders also overwrite the time_base field with some unrelated codec metadata. pkt_timebase does not exist in Libav, so an #if is required.
* vd_lavc: minor simplificationwm42016-08-231-3/+1
| | | | The timebase is now always valid.
* vd_lavc: remove unnecessary initializationwm42016-08-191-1/+0
| | | | This is already the default value.
* video/audio: always provide "proper" timestamps to libavcodecwm42016-08-191-4/+1
| | | | | | | | | | | | | | | | | | | Instead of passing through double float timestamps opaquely, pass real timestamps. Do so by always setting a valid timebase on the AVCodecContext for audio and video decoding. Specifically try not to round timestamps to a too coarse timebase, which could round off small adjustments to timestamps (such as for start time rebasing or demux_timeline). If the timebase is considered too coarse, make it finer. This gets rid of the need to do this specifically for some hardware decoding wrapper. The old method of passing through double timestamps was also a bit questionable. While libavcodec is not supposed to interpret timestamps at all if no timebase is provided, it was needlessly tricky. Also, it actually does compare them with AV_NOPTS_VALUE. This change will probably also reduce confusion in the future.
* videotoolbox: add --hwdec=videotoolbox-copy for h/w accelerated decoding ↵Aman Gupta2016-07-151-0/+2
| | | | with video filters
* vd_lavc: expose mastering display side data reference peakNiklas Haas2016-07-031-0/+25
| | | | | | | | | | | | | | | | | | | This greatly improves the result when decoding typical (ST.2084) HDR content, since the job of tone mapping gets significantly easier when you're only mapping from 1000 to 250, rather than 10000 to 250. The difference is so drastic that we can now even reasonably use `hdr-tone-mapping=linear` and get a very perceptually uniform result that is only slightly darker than normal. (To compensate for the extra dynamic range) Due to weird implementation details, this only seems to be present on keyframes (or something like that), so we have to cache the last seen value for the frames in between. Also, in some files the metadata is just completely broken / nonsensical, so I decided to apply a simple heuristic to detect completely broken metadata.
* mp_image: split colorimetry metadata into its own structNiklas Haas2016-07-031-4/+6
| | | | | | | | | | | | | | | | | | This has two reasons: 1. I tend to add new fields to this metadata, and every time I've done so I've consistently forgotten to update all of the dozens of places in which this colorimetry metadata might end up getting used. While most usages don't really care about most of the metadata, sometimes the intend was simply to “copy” the colorimetry metadata from one struct to another. With this being inside a substruct, those lines of code can now simply read a.color = b.color without having to care about added or removed fields. 2. It makes the type definitions nicer for upcoming refactors. In going through all of the usages, I also expanded a few where I felt that omitting the “young” fields was a bug.
* vd_lavc: hide structs behind platform flagsBen Boeckel2016-07-011-0/+4
| | | | Otherwise, warnings about them being unused appear.
* video: add --hwdec=auto-copy modewm42016-05-111-3/+9
| | | | | | | | This uses the normal autoprobing rules like "auto", but rejects anything that isn't flagged as copying data back to system memory. The chunk in command.c was dead code, so remove it instead of updating it.
* build: merge d3d11va and dxva2 hwaccel checkswm42016-05-111-5/+1
| | | | | | We don't have any reason to disable either. Both are loaded dynamically at runtime anyway. There is also no reason why dxva2 would disappear from libavcodec any time soon.
* video: refactor how VO exports hwdec device handleswm42016-05-091-11/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | The main change is with video/hwdec.h. mp_hwdec_info is made opaque (and renamed to mp_hwdec_devices). Its accessors are mainly thread-safe (or documented where not), which makes the whole thing saner and cleaner. In particular, thread-safety rules become less subtle and more obvious. The new internal API makes it easier to support multiple OpenGL interop backends. (Although this is not done yet, and it's not clear whether it ever will.) This also removes all the API-specific fields from mp_hwdec_ctx and replaces them with a "ctx" field. For d3d in particular, we drop the mp_d3d_ctx struct completely, and pass the interfaces directly. Remove the emulation checks from vaapi.c and vdpau.c; they are pointless, and the checks that matter are done on the VO layer. The d3d hardware decoders might slightly change behavior: dxva2-copy will not use the VO device anymore if the VO supports proper interop. This pretty much assumes that any in such cases the VO will not use any form of exclusive mode, which makes using the VO device in copy mode unnecessary. This is a big refactor. Some things may be untested and could be broken.
* 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-271-0/+2
| | | | | | | | | | | | | | | | | | | 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.
* 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.
* vd_lavc: simplify some unneeded ifdefferywm42016-04-251-8/+2
| | | | These were for ancient libavcodec versions.