summaryrefslogtreecommitdiffstats
path: root/video/decode
Commit message (Collapse)AuthorAgeFilesLines
* video: add vda decode support (with hwaccel) and direct renderingStefano Pigozzi2013-08-222-6/+223
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Decoding H264 using Video Decode Acceleration used the custom 'vda_h264_dec' decoder in FFmpeg. The Good: This new implementation has some advantages over the previous one: - It works with Libav: vda_h264_dec never got into Libav since they prefer client applications to use the hwaccel API. - It is way more efficient: in my tests this implementation yields a reduction of CPU usage of roughly ~50% compared to using `vda_h264_dec` and ~65-75% compared to h264 software decoding. This is mainly because `vo_corevideo` was adapted to perform direct rendering of the `CVPixelBufferRefs` created by the Video Decode Acceleration API Framework. The Bad: - `vo_corevideo` is required to use VDA decoding acceleration. - only works with versions of ffmpeg/libav new enough (needs reference refcounting). That is FFmpeg 2.0+ and Libav's git master currently. The Ugly: VDA was hardcoded to use UYVY (2vuy) for the uploaded video texture. One one end this makes the code simple since Apple's OpenGL implementation actually supports this out of the box. It would be nice to support other output image formats and choose the best format depending on the input, or at least making it configurable. My tests indicate that CPU usage actually increases with a 420p IMGFMT output which is not what I would have expected. NOTE: There is a small memory leak with old versions of FFmpeg and with Libav since the CVPixelBufferRef is not automatically released when the AVFrame is deallocated. This can cause leaks inside libavcodec for decoded frames that are discarded before mpv wraps them inside a refcounted mp_image (this only happens on seeks). For frames that enter mpv's refcounting facilities, this is not a problem since we rewrap the CVPixelBufferRef in our mp_image that properly forwards CVPixelBufferRetain/CvPixelBufferRelease calls to the underying CVPixelBufferRef. So, for FFmpeg use something more recent than `b3d63995` for Libav the patch was posted to the dev ML in July and in review since, apparently, the proposed fix is rather hacky.
* vaapi: use highest available profile, instead of mapping it exactlywm42013-08-191-41/+38
| | | | | | | Now the code does the same as the original MPlayer VAAPI patch, instead of trying to map the profiles exactly. See previous commit for justification and discussion.
* vdpau: don't try to match codec profileswm42013-08-191-27/+11
| | | | | | | | | | | | | | | | Instead, do what MPlayer did all these years. It worked for them, so there's probably no reason to change this. Apparently fixes playback with some files, where the VDPAU decoder does not formally support a profile, but decoding works with a more powerful profile anyway. Though note that MPlayer did this because it couldn't do it in a better way (no decoder reported profiles available when creating the VDPAU decoder), so it's not entirely clear whether this is a good idea. An alterbative implementation might try to map the profiles exactly, and do some fall backs if the exact profile is not available. But this hack-solution works too.
* vdpau_old: add forgotten probe callbackwm42013-08-151-0/+1
| | | | Could make it crash if the VO didn't support vdpau decoding.
* vdpau: fix compilation on Libavwm42013-08-151-0/+1
| | | | | | Libav's <libavcodec/vdpau.h> header uses some libavocdec symbols without forward-declaring them and without including the headers declaring them. FFmpeg's header for this is fine.
* video/decode: change fix_image callbackwm42013-08-153-5/+7
| | | | | This might make it slightly easier when trying to implement surface read-back for hardware decoding.
* vd_lavc: fix comment, document hwdec video frame size trickinesswm42013-08-151-1/+4
| | | | | | | | | About this issue, it would be better if the surfaces could be allocated with the real size, and the vdpau video mixer could be created with that size as well. That would be a bit hard, because the real surface size had to be communicated to vdpau. So I'm going with this solution. vaapi seems to be fine with either surface size, so there's hopefully no problem.
* video/decode: pass parameters directly to hwdec allocate_image callbackwm42013-08-155-20/+14
| | | | | | Instead of passing AVFrame. This also moves the mysterious logic about the size of the allocated image to common code, instead of duplicating it everywhere.
* video: add vaapi decode and output supportwm42013-08-124-0/+420
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is based on the MPlayer VA API patches. To be exact it's based on a very stripped down version of commit f1ad459a263f8537f6c from git://gitorious.org/vaapi/mplayer.git. This doesn't contain useless things like benchmarking hacks and the demo code for GLX interop. Also, unlike in the original patch, decoding and video output are split into separate source files (the separation between decoding and display also makes pixel format hacks unnecessary). On the other hand, some features not present in the original patch were added, like screenshot support. VA API is rather bad for actual video output. Dealing with older libva versions or the completely broken vdpau backend doesn't help. OSD is low quality and should be rather slow. In some cases, only either OSD or subtitles can be shown at the same time (because OSD is drawn first, OSD is prefered). Also, libva can't decide whether it accepts straight or premultiplied alpha for OSD sub-pictures: the vdpau backend seems to assume premultiplied, while a native vaapi driver uses straight. So I picked straight alpha. It doesn't matter much, because the blending code for straight alpha I added to img_convert.c is probably buggy, and ASS subtitles might be blended incorrectly. Really good video output with VA API would probably use OpenGL and the GL interop features, but at this point you might just use vo_opengl. (Patches for making HW decoding with vo_opengl have a chance of being accepted.) Despite these issues, decoding seems to work ok. I still got tearing on the Intel system I tested (Intel(R) Core(TM) i3-2350M). It was also tested with the vdpau vaapi wrapper on a nvidia system; however this was rather broken. (Fortunately, there is no reason to use mpv's VAAPI support over native VDPAU.)
* video: redo hw decoding initialization, add --hwdec=autowm42013-08-114-99/+195
| | | | | | | | | | | | | | | | Change how the HW decoding stuff is organized, the way it's initialized in particular. Instead of duplicating the list of supported codecs for hwaccel decoders, add a probe function which allows each decoder to report whether it supports a given codec. Add an "auto" choice to the --hwdec option, which automatically enables hardware decoding if libavcodec and/or the VO supports it. What mpv prints on the terminal changes a bit. Now it will just print a single line whether hw decoding is used or not (and nothing at all if no hw decoding at all was requested). The pretty violent fallback from hw decoding to software decoding is still quite verbose and evil-looking though.
* core: move contents to mpvcore (2/2)Stefano Pigozzi2013-08-064-13/+13
| | | | Followup commit. Fixes all the files references.
* vd_lavc: print warning if hardware decoding API is not availablewm42013-07-301-0/+3
| | | | | At least currently, this case pretty much happens only in the case vdpau is requested, but not compiled in.
* vd_lavc: fix CONFIG_VDPAU checkwm42013-07-301-1/+1
| | | | | | CONFIG_VDPAU was just defined to 0, instead of undefined when vdpau was unavailable. I blame the old mplayer code, which apparently can't have consistent conventions.
* vdpau: split off decoder parts, use "new" libavcodec vdpau hwaccel APIwm42013-07-286-73/+587
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Move the decoder parts from vo_vdpau.c to a new file vdpau_old.c. This file is named so because because it's written against the "old" libavcodec vdpau pseudo-decoder (e.g. "h264_vdpau"). Add support for the "new" libavcodec vdpau support. This was recently added and replaces the "old" vdpau parts. (In fact, Libav is about to deprecate and remove the "old" API without deprecation grace period, so we have to support it now. Moreover, there will probably be no Libav release which supports both, so the transition is even less smooth than we could hope, and we have to support both the old and new API.) Whether the old or new API is used is checked by a configure test: if the new API is found, it is used, otherwise the old API is assumed. Some details might be handled differently. Especially display preemption is a bit problematic with the "new" libavcodec vdpau support: it wants to keep a pointer to a specific vdpau API function (which can be driver specific, because preemption might switch drivers). Also, surface IDs are now directly stored in AVFrames (and mp_images), so they can't be forced to VDP_INVALID_HANDLE on preemption. (This changes even with older libavcodec versions, because mp_image always uses the newer representation to make vo_vdpau.c simpler.) Decoder initialization in the new code tries to deal with codec profiles, while the old code always uses the highest profile per codec. Surface allocation changes. Since the decoder won't call config() in vo_vdpau.c on video size change anymore, we allow allocating surfaces of arbitrary size instead of locking it to what the VO was configured. The non-hwdec code also has slightly different allocation behavior now. Enabling the old vdpau special decoders via e.g. --vd=lavc:h264_vdpau doesn't work anymore (a warning suggesting the --hwdec option is printed instead).
* lavc_dr1: make reference counting thread-safewm42013-07-281-4/+39
| | | | | | | | See previous commits. This time, the lock is kept for rather long times (e.g. for the duration of a big image memory allocation), but this (probably) still doesn't matter at all. This also affects legacy code only (pre-refcounting libavcodec).
* Fix some -Wshadow warningswm42013-07-231-4/+4
| | | | | | In general, this warning can hint to actual bugs. We don't enable it yet, because it would conflict with some unmerged code, and we should check with clang too (this commit was done by testing with gcc).
* video: remove fullscreen flags chaoswm42013-07-181-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There was a MPOpts fullscreen field, a mp_vo_opts.fs field, and VOFLAG_FULLSCREEN. Remove all these and introduce a mp_vo_opts.fullscreen flag instead. When VOs receive VOCTRL_FULLSCREEN, they are supposed to set the current fullscreen mode to the state in mp_vo_opts.fullscreen. They also should do this implicitly on config(). VOs which are capable of doing so can update the mp_vo_opts.fullscreen if the actual fullscreen mode changes (e.g. if the user uses the window manager controls). If fullscreen mode switching fails, they can also set mp_vo_opts.fullscreen to the actual state. Note that the X11 backend does almost none of this, and it has a private fs flag to store the fullscreen flag, instead of getting it from the WM. (Possibly because it has to deal with broken WMs.) The fullscreen option has to be checked on config() to deal with the -fs option, especially with something like: mpv --fs file1.mkv --{ --no-fs file2.mkv --} (It should start in fullscreen mode, but go to windowed mode when playing file2.mkv.) Wayland changes by: Alexander Preisinger <alexander.preisinger@gmail.com> Cocoa changes by: Stefano Pigozzi <stefano.pigozzi@gmail.com>
* video: redo how colorspaces are handledwm42013-07-163-45/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of handling colorspaces with VFCTRLs/VOCTRLs, make them part of the normal video format negotiation. The colorspace is passed down like other video params with config/reconfig calls. Forcing colorspaces (via the --colormatrix options and properties) is handled differently too: if it's changed, completely reinit the video chain. This is slower and requires a precise seek to the same position to perform an update, but it's simpler and less bug-prone. Considering switching the colorspace at runtime by user-interaction is a rather obscure feature, this is a good change. The colorspace VFCTRLs and VOCTRLs are still kept. The VOs rely on it, and would have to be changed to get rid of them. We'll do that later, and convert them incrementally instead of in one go. Note that controlling the output range now always works on VO level. Basically, this means you can't get vf_scale to output full-range YUV for whatever reason. If that is really wanted, it should be a vf_scale option. the previous behavior didn't make too much sense anyway. This commit fixes a few bugs (such as playing RGB video and converting that to YUV with vf_scale - a recent commit broke this and forced the VO to display YUV as RGB if possible), and might introduce some new ones.
* Fix build on Libav stable (dammit)wm42013-07-151-0/+8
| | | | | | | The previous commit fixed Libav git, but it was still broken on Libav 9.8. Also, while we're at it, add a note to lavc_dr1.c and its status.
* vd: add VDCTRL_GET_PARAMSwm42013-07-152-0/+4
| | | | | | This is probably going to be unused, but might help with debugging and such. It returns the image parameters as determined by the video decoder.
* video: unify colorspace setupwm42013-07-153-21/+36
| | | | | | | | | | Guess the colorspace directly in mpcodecs_reconfig_vo(), instead of in set_video_colorspace(). The difference is that the latter function just makes the video filter chain (and VOs) force the detected colorspace, and then throws it away, while the former is a bit more general and central. Not really a big difference and it doesn't matter much in practice, but it guarantees that there is no internal disagreement about the colorspace.
* vf: add vf_control wrapperwm42013-07-151-6/+6
| | | | | Slightly cleaner, although rather redundant. But still, why wasn't this added 10 years ago?
* dec_video: add vd_control wrapperwm42013-07-152-7/+12
| | | | Slightly cleaner.
* Cleanup some include statementswm42013-07-122-4/+1
|
* Remove old demuxerswm42013-07-071-4/+1
| | | | | | | | | | Delete demux_avi, demux_asf, demux_mpg, demux_ts. libavformat does better than them (except in rare corner cases), and the demuxers have a bad influence on the rest of the code. Often they don't output proper packets, and require additional audio and video parsing. Most work only in --no-correct-pts mode. Remove them to facilitate further cleanups.
* vo_opengl: handle chroma locationwm42013-06-281-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use the video decoder chroma location flags and render chroma locations other than centered. Until now, we've always used the intuitive and obvious centered chroma location, but H.264 uses something else. FFmpeg provides a small overview in libavcodec/avcodec.h: ----------- /** * X X 3 4 X X are luma samples, * 1 2 1-6 are possible chroma positions * X X 5 6 X 0 is undefined/unknown position */ enum AVChromaLocation{ AVCHROMA_LOC_UNSPECIFIED = 0, AVCHROMA_LOC_LEFT = 1, ///< mpeg2/4, h264 default AVCHROMA_LOC_CENTER = 2, ///< mpeg1, jpeg, h263 AVCHROMA_LOC_TOPLEFT = 3, ///< DV AVCHROMA_LOC_TOP = 4, AVCHROMA_LOC_BOTTOMLEFT = 5, AVCHROMA_LOC_BOTTOM = 6, AVCHROMA_LOC_NB , ///< Not part of ABI }; ----------- The visual difference is literally minimal, but since videophiles apparently consider this detail as quality mark of a video renderer, support it anyway. We don't bother with chroma locations other than centered and left, though. Not sure about correctness, but it's probably ok.
* video: add a new method to configure filters and VOswm42013-06-284-28/+47
| | | | | | | | | | | | | | | | | | The filter chain and the video ouputs have config() functions. They are strictly limited to transfering the video size and format. Other parameters (like color levels) have to be transferred separately. Improve upon this by introducing a separate set of reconfig() functions, which use mp_image_params to carry format parameters. This struct contains all image format related parameters from config(), plus additional parameters such as colorspace. Change vf_rotate to use it, as well as vo_opengl. vf_rotate is just an example/test case, but vo_opengl will need it later. The intention is also to get rid of VOCTRL_SET_YUV_COLORSPACE. This information is now handed to the VOs via reconfig(). The getter, VOCTRL_GET_YUV_COLORSPACE, will still be needed though.
* options: remove -lavdopts debug suboptionwm42013-06-281-4/+0
| | | | This can be set as avopt instead.
* osdep: remove shmem wrapperwm42013-06-181-1/+0
| | | | This is unused now that the cache is always threaded.
* core: add common function to initialize AVPacketwm42013-06-031-11/+2
| | | | | | | | | | Audio and video had their own (very similar) functions to initialize an AVPacket (ffmpeg's packet struct) from a demux_packet (mplayer's packet struct). Add a common function for these. Also use this function for sd_lavc_conv. This is actually a functional change, as some libavfilter subtitle demuxers add weird out-of-band stuff as side-data.
* options: remove some questionable -lavdopts suboptionswm42013-05-291-15/+0
| | | | | | Most of these are rather questionable, the rest you rarely need to set manually. You still can set all of them with -lavdopts-o (because libavcodec has AVOptions for them).
* dec_video: get rid of two global variableswm42013-05-212-8/+3
|
* dec_video: remove emms usagewm42013-05-211-10/+0
| | | | | | | libavcodec generally shouldn't have this problem anymore (if libavcodec ever had it). All other video decoders are gone. In any case, if this commit actually causes regressions, these are libavcodec bugs and should be fixed there instead.
* core: allow changing filter filters at runtimewm42013-05-181-0/+1
| | | | | | | | | | | | | | | | Add the "vf" command, which allows changing the video filter chain at runtime. For example, the 'y' key could be bound to toggle deinterlacing by adding 'y vf toggle yadif' to the input.conf. Reconfiguring the video filter chain normally resets the VO, so that it will be "stuck" until a new video frame is rendered. To mitigate this, a seek to the current position is issued when the filter chain is changed. This is done only if playback is paused, because normal playback will show an actual new frame quickly enough. If vdpau hardware decoding is used, filter insertion (whether it fails or not) will break the video for a while. This is because vo_vdpau resets decoding related things on vo_config().
* vd_lavc: change VDCTRL_REINIT_VO behaviorwm42013-05-181-3/+1
| | | | | | | | | | | | | This tried to use ctx->pic (last decoded AVFrame) for the frame bounds. However, if av_frame_unref() on the AVFrame is called, the function will reset _all_ AVFrame fields, even those which are not involved with memory management. As result, mpcodecs_config_vo() was called with 0 width/height, which made the function exit early, instead of reconfiguring the filter chain. Go back to using mpcodecs_config_vo() directly. (That's what it did before this VDCTRL was originally introduced; the original reason for it disappeared.)
* video: rename VDCTRL_RESET_ASPECT to VDCTRL_REINIT_VOwm42013-05-184-5/+5
| | | | Same thing, and VDCTRL_REINIT_VO implies more generic use.
* vd_lavc: hack-fix vdpau decoding with non mod 16 videowm42013-05-141-1/+10
| | | | | | | This changes the code so that it does the same as MPlayer, mplayer2 and mpv before ref-counted AVFrame. The problem is that get_buffer2 is called with aligned frame dimensions, while get_buffer didn't. This breaks the mpv video frame size change detection.
* video: add --hwdec-codecs option to whitelist codecs for hw decodingwm42013-05-041-3/+16
|
* vd_lavc: allow explicitly selecting vdpau hw decoderswm42013-05-041-1/+11
| | | | | | | | | | | | This allows using the vdpau decoders with -vd without having to use the -hwdec switch (basically like in mplayer). Note that this way of selecting the hardware decoder is still deprecated. libavcodec went away from adding special decoder entries for hardware decoding, and instead makes use of the "hwaccel" architecture, where hardware decoders use the same decoder names as the software decoders. The old vdpau special decoders will probably be deprecated and removed in the future.
* vd_lavc: fix decoder init failure pathwm42013-04-271-14/+18
| | | | | | | | | libavcodec decoder initialization failure caused a segfault, because it wasn't properly reported back in init(). Also remove the return value from init_avctx(), which actually makes things simpler. Instead, ctx->avctx can be checked to see whether initialization was ok.
* core: always pass data via packet fields to video decoderswm42013-03-284-16/+11
| | | | | | | Makes the code a bit simpler to follow, at least in the "modern" decoding path (update_video_nocorrect_pts() is used with old demuxers, which don't return proper packets and need further parsing, so this code looks less simple now).
* video: make use of libavcodec refcountingwm42013-03-132-10/+77
| | | | Now lavc_dr1.c is not used anymore if libavcodec is recent enough.
* video: prepare for libavcodec refcountingwm42013-03-131-46/+40
| | | | | Some minor refactoring and moving code around. There should be no functional changes.
* vo: remove and cleanup globalsAlexander Preisinger2013-03-041-10/+10
| | | | | | | | Removes almost every global variabel in vo.h and puts them in a special struct in MPOpts for video output related options. Also we completly remove the options/globals pts and refresh rate because they were unused.
* m_option: don't define OPT_BASE_STRUCT by defaultwm42013-03-011-0/+2
| | | | | | | | | | | OPT_BASE_STRUCT defines which struct the OPT_ macros (like OPT_INT etc.) reference implicitly, since these macros take struct member names but no struct type. Normally, only cfg-mplayer.h should need this, and other places shouldn't be bothered with having to #undef it. (Some files, like demux_lavf.c, still store their options in MPOpts. In the long term, this should be removed, and handled like e.g. with VO suboptions instead.)
* video/out: remove video mode switching (--vm)wm42013-02-261-3/+2
| | | | | | | | | | | | | | | | | | | | This allowed making the player switch the monitor video mode when creating the video window. This was a questionable feature, and with today's LCD screens certainly not useful anymore. Switching to a random video mode (going by video width/height) doesn't sound too useful either. I'm not sure about the win32 implementation, but the X part had several bugs. Even in mplayer-svn (where x11_common.c hasn't been receiving any larger changes for a long time), this code is buggy and doesn't do the right thing anyway. (And what the hell _did_ it do when using multiple physical monitors?) If you really want this, write a shell script that calls xrandr before and after calling mpv. vo_sdl still can do mode switching, because SDL has native support for it, and using it is trivial. Add a new sub-option for this.
* dec_video: remove weird offset for VDCTRL_QUERY_UNSEEN_FRAMESwm42013-02-262-5/+6
| | | | | The return value of get_current_video_decoder_lag() should be the same before and after this