summaryrefslogtreecommitdiffstats
path: root/video/decode
Commit message (Collapse)AuthorAgeFilesLines
* dxva2: support HEVCwm42015-05-141-1/+8
| | | | | | | | | | | | This is pretty much copy&pasted from Libav commit a7e0380497306d9723dec8440a4c52e8bf0263cf. Note that if FFmpeg was not compiled with HEVC DXVA2 support or your video drivers do not support HEVC, the player will not fallback and just fail decoding any video. This is because libavcodec appears not to return an error in this case. The situation is made worse by the fact that MSYS2 is on an ancient MinGW-w64 release, which does not have the required headers for HEVC DXVA2 support.
* vda: add support for nv12 image formatsStefano Pigozzi2015-05-131-1/+9
| | | | | | | | | The hardware always decodes to nv12 so using this image format causes less cpu usage than uyvy (which we are currently using, since Apple examples and other free software use that). The reduction in cpu usage can add up to quite a bit, especially for 4k or high fps video. This needs an accompaning commit in libavcodec.
* dxva2: fix broken build with gcc 5.1Avi Halachmi (:avih)2015-04-241-0/+5
| | | | | | gpu_mempcy should to be called from code which targets SSE Signed-off-by: wm4 <wm4@nowhere>
* video: cleanup some old log messageswm42015-04-201-9/+0
| | | | | These are basically MPlayer leftovers, and barely useful due to being redundant with other messages. The FPS message is used somewhere else.
* player: change video-bitrate and audio-bitrate propertieswm42015-04-203-8/+1
| | | | | | | | | | | | | | Remove the old implementation for these properties. It was never very good, often returned very innaccurate values or just 0, and was static even if the source was variable bitrate. Replace it with the implementation of "packet-video-bitrate". Mark the "packet-..." properties as deprecated. (The effective difference is different formatting, and returning the raw value in bits instead of kilobits.) Also extend the documentation a little. It appears at least some decoders (sipr?) need the AVCodecContext.bit_rate field set, so this one is still passed through.
* Update license headersMarcin Kurczewski2015-04-134-20/+16
| | | | Signed-off-by: wm4 <wm4@nowhere>
* vdpau: fix preemption handlingDan Oscarsson2015-03-311-0/+23
| | | | Signed-off-by: wm4 <wm4@nowhere>
* video: move colorspace overrides to vf_format, simplifywm42015-03-311-10/+0
| | | | | | | | | | | | | | | | | | | Remove the colorspace-related top-level options, add them to vf_format. They are rather obscure and not needed often, so it's better to get them out of the way. In particular, this gets rid of the semi-complicated logic in command.c (most of which was needed for OSD display and the direct feedback from the VO). It removes the duplicated color-related name mappings. This removes the ability to write the colormatrix and related properties. Since filters can be changed at runtime, there's no loss of functionality, except that you can't cycle automatically through the color constants anymore (but who needs to do this). This also changes the type of the mp_csp_names and related variables, so they can directly be used with OPT_CHOICE. This probably ended up a bit awkward, for the sake of not adding a new option type which would have used the previous format.
* RPI supportwm42015-03-293-1/+66
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This requires FFmpeg git master for accelerated hardware decoding. Keep in mind that FFmpeg must be compiled with --enable-mmal. Libav will also work. Most things work. Screenshots don't work with accelerated/opaque decoding (except using full window screenshot mode). Subtitles are very slow - even simple but huge overlays can cause frame drops. This always uses fullscreen mode. It uses dispmanx and mmal directly, and there are no window managers or anything on this level. vo_opengl also kind of works, but is pretty useless and slow. It can't use opaque hardware decoding (copy back can be used by forcing the option --vd=lavc:h264_mmal). Keep in mind that the dispmanx backend is preferred over the X11 ones in case you're trying on X11; but X11 is even more useless on RPI. This doesn't correctly reject extended h264 profiles and thus doesn't fallback to software decoding. The hw supports only up to the high profile, and will e.g. return garbage for Hi10P video. This sets a precedent of enabling hw decoding by default, but only if RPI support is compiled (which most hopefully it will be disabled on desktop Linux platforms). While it's more or less required to use hw decoding on the weak RPI, it causes more problems than it solves on real platforms (Linux has the Intel GPU problem, OSX still has some cases with broken decoding.) So I can live with this compromise of having different defaults depending on the platform. Raspberry Pi 2 is required. This wasn't tested on the original RPI, though at least decoding itself seems to work (but full playback was not tested).
* vd_lavc: less confusing message when hardware decoding won't workwm42015-03-201-2/+3
| | | | | | Codecs for hardware acceleration are not blacklisted, but whitelisted. Also, if this emssage is printed, the codec might not have any hardware acceleration support in the first place.
* player: better handling of video with no timestampswm42015-03-201-1/+7
| | | | | | | | | | | Trying to handle such video is almost worthless, but it was requested by at least 2 users. If there are no timestamps, enable byte seeking by setting ts_resets_possible. Use the video FPS (wherever it comes from) and the audio samplerate for timing. The latter was already done by making the first packet emit DTS=0; remove this again and do it "properly" in a higher level.
* player: warn against non-monotonic video PTS only oncewm42015-03-181-5/+0
| | | | | | | | For some reason there were two points in the code where it warned against non-monotonic video PTS. The one in video.c triggered on PTS going backwards or making large jumps forwards, while dec_video.c triggered on PTS going backwards or PTS not changing. Merge them into a single check, which warns against all cases.
* vd_lavc: change message about using hardware decodingwm42015-03-171-1/+1
| | | | This was requested. Apparently some find the old mesage confusing.
* video: don't drop anamorphic scaling if it's too minorwm42015-03-161-8/+1
| | | | | | | | | This played e.g. a 1264x722 file as 1264x720. There was some code which dropped the aspect ratio if the video (in original resolution) wasn't scaled by more than 4 pixels. Commit 5f3c3f8c introduced this (although I'm not really sure what the code replaced by it did). Just remove this "feature".
* vd_lavc: let --hwdec=auto select "vaapi-copy"wm42015-03-051-1/+1
| | | | | | | | | | | | Instead of "vaapi", simply by changing the probe order. "vaapi" uses the GLX GL interop, which has causing us more problems than it solved. Unfortunately this leads also to copying if "--hwdec=auto --vo=vaapi" is used, even though GLX is not involved in this case - but I don't care enough to make the probe logic cleverer just for this. You can still get the zero-copy path with --hwdec=vaapi.
* Remove some FFmpeg/Libav compatibility hackswm42015-03-031-4/+0
| | | | | | All of these are now in the supported FFmpeg and Libav versions. The 3 remaining API checks are for FFmpeg-only things.
* Revert "Revert recent vo_opengl related commits"Niklas Haas2015-02-281-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | Omitted a simple, but devastasting check. Fixed the relevant commits now. This reverts commit 8d24e9d9b8ad1b5d82139980eca148dc0f4a1eab. diff --git a/video/out/gl_video.c b/video/out/gl_video.c index 9c8a643..f1ea03e 100644 --- a/video/out/gl_video.c +++ b/video/out/gl_video.c @@ -1034,9 +1034,9 @@ static void compile_shaders(struct gl_video *p) shader_def_opt(&header_conv, "USE_CONV_GAMMA", use_conv_gamma); shader_def_opt(&header_conv, "USE_CONST_LUMA", use_const_luma); shader_def_opt(&header_conv, "USE_LINEAR_LIGHT_BT1886", - gamma_fun == MP_CSP_TRC_BT_1886); + use_linear_light && gamma_fun == MP_CSP_TRC_BT_1886); shader_def_opt(&header_conv, "USE_LINEAR_LIGHT_SRGB", - gamma_fun == MP_CSP_TRC_SRGB); + use_linear_light && gamma_fun == MP_CSP_TRC_SRGB); shader_def_opt(&header_conv, "USE_SIGMOID", use_sigmoid); if (p->opts.alpha_mode > 0 && p->has_alpha && p->plane_count > 3) shader_def(&header_conv, "USE_ALPHA_PLANE", "3");
* Revert recent vo_opengl related commitswm42015-02-281-1/+0
| | | | | | | | | | | | | | | Breaks vo_opengl by default. I'm hot able to fix this myself, because I have no clue about the overcomplicated color management logic. Also, whilethis is apparently caused by commit fbacd5, the following commits all depend on it, so revert them too. This reverts the following commits: e141caa97dade07f4d7e0d6c208bcd3493e712ed 653b0dd5295453d9661f673b4ebd02c5ceacf645 729c8b3f641e633474be612e66388c131a1b5c92 fbacd5de31de964f7cd562304ab1c9b4a0d76015 Fixes #1636.
* vd_lavc: respect lavc's color_trc fieldNiklas Haas2015-02-281-0/+1
| | | | | We now actually use the TRC tagging information lavc provides us with, instead of always manually guessing.
* video: remove redundant codec parameterswm42015-02-241-5/+0
| | | | | | | Remove coded_width and coded_height. This was originally added in commit fd7dde40, when BITMAPINFOHEADER was killed. The separate fields became redundant in commit e68f4be1. Remove them (nothing passed to the decoders actually changes with _this_ commit).
* video: un-discourage "vaapi-copy" hwdec modewm42015-02-201-5/+0
| | | | | Maybe I don't know what I'm doing. I'm fairly certain though that Intel does not know what they're doing.
* vd_lavc: uninit the hwdec backend after closing the decoderwm42015-02-141-6/+3
| | | | | | | | | | | | | | | | | A recent behavior change in libavcodec's h264 decoder keeps at least 1 surface even after avcodec_flush_buffers() has been called. We used to flush the decoder in order to make sure all surfaces are free'd, so that the hw decoder can be safely uninitialized. This doesn't work anymore. Fix it by closing the AVCodecContext before the hw decoder is uninitialized. This is actually simpler and more robust. It seems to be well-supported too. Fixes invalid read accesses with vaapi-copy and dxva2-copy. These destroyed the hwdec API fully on uninit, and could not deal with surfaces surviving the decoder. Probably fixes #1587.
* video: work around libswscale for PNG pixel formatswm42015-02-061-1/+2
| | | | | | | | The intention is that we can test vo_opengl with high bit depth PNGs better. This throws libswscale completely out of the loop, which before was needed in order to convert from big endian to little endian. Also apply a minimal cleanup to fmt-conversion.c (unrelated).
* command: add property returning detected hwdec APIwm42015-02-021-12/+0
| | | | | | | | | This is somewhat imperfect, because detection of hw decoding APIs is mostly done on demand, and often avoided if not necessary. (For example, we know very well that there are no hw decoders for certain codecs.) This also requires every hwdec backend to identify itself (see hwdec.h changes).
* video: have a generic context struct for hwdec backendswm42015-01-222-8/+6
| | | | | | | | | | | Before this commit, each hw backend had their own specific struct types for context, and some, like VDA, had none at all. Add a context struct (mp_hwdec_ctx) that provides a somewhat generic way to pass the hwdec context around. Some things get slightly better, some slightly more verbose. mp_hwdec_info is still around; it's still needed, but is reduced to its role of handling delayed loading of the hwdec backend.
* win32: request UTF-16 API variants, Vista+ APIs, and COM C macroswm42015-01-071-7/+2
| | | | | Put the Vista+ (_WIN32_WINNT) and the COM C (COBJMACROS) defines into the build system, instead of defining them over and over in the code.
* dxva2: copy mp_image attributes to sw_imgJames Ross-Gowan2015-01-071-0/+1
|
* player: print used number of threads in verbose modewm42015-01-051-1/+1
| | | | Also, don't use av_log() for mpv output.
* vd_lavc: fix error handling pathwm42014-12-131-11/+12
| | | | The ctx->pic check must uninitialize the decoder.
* Check some mallocswm42014-12-121-0/+4
| | | | Fixes #1337.
* vd_lavc: use avcodec_is_open()wm42014-12-021-1/+1
| | | | | This is "better", although nobody seems to know how this API is supposed to work at all.
* vd_lavc: don't crash if codec could not be openedwm42014-12-011-1/+1
| | | | Fixes #1307.
* vd_lavc: flush frames before uninitializing hw decoderwm42014-11-201-0/+3
| | | | | | This way, no surfaces are in use when uninitializing the hw decoders, which might help with -copy hw decoders (normal hw decoding is not affected).
* dxva2: use gpu_memcpy with unmatched stridesJames Ross-Gowan2014-10-271-8/+29
| | | | Like memcpy_pic, this checks if the strides match first.
* dxva2: fix copying surfaces with different strideJames Ross-Gowan2014-10-271-10/+18
|
* dxva2: fix crash on initialization failurewm42014-10-261-0/+2
| | | | If dxva2_init() fails, dxva2_uninit() will be called twice.
* dxva2: gpu_memcpy: fix build for GCC 4.8.3James Ross-Gowan2014-10-261-3/+10
|
* dxva2: use optimized memcpyJames Ross-Gowan2014-10-262-11/+164
| | | | | | At least on my machine, reading back the frame with system memcpy is slower than just using software rendering. Use the optimized gpu_memcpy from LAV to speed things up.
* video: initial dxva2 supportwm42014-10-253-0/+611
| | | | | Shamelessly stolen from ffmpeg. It probably doesn't work - you can debug it yourself.
* vd_lavc: fix a small memory leak on init errorwm42014-09-292-8/+5
| | | | | The private context wasn't free'd when codec init failed. Restructure the code so that it can't happen.
* Remove mpbswap.hwm42014-09-251-1/+0
| | | | | | This was once central, but now it's almost unused. Only vf_divtc still uses it for extremely weird and incomprehensible reasons. The use in stream.c is trivial. Replace these, and remove mpbswap.h.
* video: remove BITMAPINFOHEADER from internal demuxer APIwm42014-09-251-14/+7
| | | | | | | | | | MPlayer traditionally did this because it made sense: the most important formats (avi, asf/wmv) used Microsoft formats, and many important decoders (win32 binary codecs) also did. But the world has changed, and I've always wanted to get rid of this thing from the codebase. demux_mkv.c internally still uses it, because, guess what, Matroska has a VfW muxing mode, which uses these data structures natively.
* build: handle insane libavcodec API bullshitwm42014-09-051-11/+25
| | | | | | | | | | | | | | | | | | | | | The oldest supported FFmpeg release doesn't provide av_vdpau_alloc_context(). With these versions, the application has no other choice than to hard code the size of AVVDPAUContext. (On the other hand, there's av_alloc_vdpaucontext(), which does the same thing, but is FFmpeg specific - not sure if it was available early enough, so I'm not touching it.) Newer FFmpeg and Libav releases require you to call this function, for ABI compatibility reasons. It's the typcal lakc of foresight that make FFmpeg APIs terrible. mpv successfully pretended that this crap didn't exist (ABI compat. is near impossible to reach anyway) - but it appears newer developments in Libav change the function from initializing the struct with all-zeros to something else, and mpv vdpau decoding would stop working as soon as this new work is relewased. So, add a configure test (sigh). CC: @mpv-player/stable
* video: initial Matroska 3D supportwm42014-08-301-0/+2
| | | | | | | | | | | | | | | | | | | | | This inserts an automatic conversion filter if a Matroska file is marked as 3D (StereoMode element). The basic idea is similar to video rotation and colorspace handling: the 3D mode is added as a property to the video params. Depending on this property, a video filter can be inserted. As of this commit, extending mp_image_params is actually completely unnecessary - but the idea is that it will make it easier to integrate with VOs supporting stereo 3D mogrification. Although vo_opengl does support some stereo rendering, it didn't support the mode my sample file used, so I'll leave that part for later. Not that most mappings from Matroska mode to vf_stereo3d mode are probably wrong, and some are missing. Assuming that Matroska modes, and vf_stereo3d in modes, and out modes are all the same might be an oversimplification - we'll see. See issue #1045.
* Move compat/ and bstr/ directory contents somewhere elsewm42014-08-291-4/+2
| | | | | | | | | bstr.c doesn't really deserve its own directory, and compat had just a few files, most of which may as well be in osdep. There isn't really any justification for these extra directories, so get rid of them. The compat/libav.h was empty - just delete it. We changed our approach to API compatibility, and will likely not need it anymore.
* vaapi: try dealing with Intel's braindamaged shit driverswm42014-08-213-0/+37
| | | | | | | | | | | | | | | | | | | | | | | | So talking to a certain Intel dev, it sounded like modern VA-API drivers are reasonable thread-safe. But apparently that is not the case. Not at all. So add approximate locking around all vaapi API calls. The problem appeared once we moved decoding and display to different threads. That means the "vaapi-copy" mode was unaffected, but decoding with vo_vaapi or vo_opengl lead to random crashes. Untested on real Intel hardware. With the vdpau emulation, it seems to work fine - but actually it worked fine even before this commit, because vdpau was written and designed not by morons, but competent people (vdpau is guaranteed to be fully thread-safe). There is some probability that this commit doesn't fix things entirely. One problem is that locking might not be complete. For one, libavcodec _also_ accesses vaapi, so we have to rely on our own guesses how and when lavc uses vaapi (since we disable multithreading when doing hw decoding, our guess should be relatively good, but it's still a lavc implementation detail). One other reason that this commit might not help is Intel's amazing potential to fuckup anything that is good and holy.
* vaapi: we need more surfaceswm42014-08-181-1/+2
| | | | | | | Playing with high framedrop could make it run out of surfaces. In theory, we wouldn't need an additional surface, if we could just clear the vo_vaapi internal surface - but doing so would probably be a pain, so I don't care.
* video: move display and timing to a separate threadwm42014-08-121-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The VO is run inside its own thread. It also does most of video timing. The playloop hands the image data and a realtime timestamp to the VO, and the VO does the rest. In particular, this allows the playloop to do other things, instead of blocking for video redraw. But if anything accesses the VO during video timing, it will block. This also fixes vo_sdl.c event handling; but that is only a side-effect, since reimplementing the broken way would require more effort. Also drop --softsleep. In theory, this option helps if the kernel's sleeping mechanism is too inaccurate for video timing. In practice, I haven't ever encountered a situation where it helps, and it just burns CPU cycles. On the other hand it's probably actively harmful, because it prevents the libavcodec decoder threads from doing real work. Side note: Originally, I intended that multiple frames can be queued to the VO. But this is not done, due to problems with OSD and other certain features. OSD in particular is simply designed in a way that it can be neither timed nor copied, so you do have to render it into the video frame before you can draw the next frame. (Subtitles have no such restriction. sd_lavc was even updated to fix this.) It seems the right solution to queuing multiple VO frames is rendering on VO-backed framebuffers, like vo_vdpau.c does. This requires VO driver support, and is out of scope of this commit. As consequence, the VO has a queue size of 1. The existing video queue is just needed to compute frame duration, and will be moved out in the next commit.
* video: don't keep multiple pointers to hwdec info structwm42014-08-112-3/+3
| | | | This makes a certain corner case simpler at a later point.
* vaapi: fix uninitialized value readwm42014-08-111-1/+1
| | | | | | Found with valgrind. This is somewhat terrifying, because the VA-API API function is supposed to fill these values, and we access them only if the API functions return success. So this shouldn't have happened.
* video: remove "hard" framedrop modewm42014-08-091-5/+10
| | | | | | | | | Completely useless, and could accidentally be enabled by cycling framedrop modes. Just get rid of it. But still allow triggering the old code with --vd-lavc-framedrop, in case someone asks for it. If nobody does, this new option will be removed eventually.
* Improve setting AVOptionswm42014-08-021-11/+3
| | | | | | | | Use OPT_KEYVALUELIST() for all places where AVOptions are directly set from mpv command line options. This allows escaping values, better diagnostics (also no more "pal"), and somehow reduces code size. Remove the old crappy option parser (av_opts.c).
* vda: only support the new hwaccel 1.2 API (remove old code)Stefano Pigozzi2014-08-011-145/+13
| | | | | | | | | Since the new hwaccel API is now merged in ffmpeg's stable release, we can finally remove support for the old API. I pretty much kept lu_zero's new code unchanged and just added some error printing (that we had with the old glue code) to make the life of our users less miserable.
* dvd, bluray, cdda: add demux_disc containing all related hackswm42014-07-052-4/+0
| | | | | | | | | | | | DVD and Bluray (and to some extent cdda) require awful hacks all over the codebase to make them work. The main reason is that they act like container, but are entirely implemented on the stream layer. The raw mpeg data resulting from these streams must be "extended" with the container-like metadata transported via STREAM_CTRLs. The result were hacks all over demux.c and some higher-level parts. Add a "disc" pseudo-demuxer, and move all these hacks and special-cases to it.
* options: Expose --colormatrix-primaries to the userNiklas Haas201