summaryrefslogtreecommitdiffstats
path: root/video/decode/vd_lavc.c
Commit message (Collapse)AuthorAgeFilesLines
* 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).
* video: initial dxva2 supportwm42014-10-251-0/+4
| | | | | 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-291-7/+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.
* 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-211-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | 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.
* video: don't keep multiple pointers to hwdec info structwm42014-08-111-2/+2
| | | | This makes a certain corner case simpler at a later point.
* 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).
* video: Add support for non-BT.709 primariesNiklas Haas2014-06-221-0/+1
| | | | | | | This add support for reading primary information from lavc, categorized into BT.601-525, BT.601-625, BT.709 and BT.2020; and passes it on to the vo. In vo_opengl, we always generate the 3dlut against the wider BT.2020 and transform our source into this colorspace in the shader.
* video: introduce failure path for image allocationswm42014-06-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Until now, failure to allocate image data resulted in a crash (i.e. abort() was called). This was intentional, because it's pretty silly to degrade playback, and in almost all situations, the OOM will probably kill you anyway. (And then there's the standard Linux overcommit behavior, which also will kill you at some point.) But I changed my opinion, so here we go. This change does not affect _all_ memory allocations, just image data. Now in most failure cases, the output will just be skipped. For video filters, this coincidentally means that failure is treated as EOF (because the playback core assumes EOF if nothing comes out of the video filter chain). In other situations, output might be in some way degraded, like skipping frames, not scaling OSD, and such. Functions whose return values changed semantics: mp_image_alloc mp_image_new_copy mp_image_new_ref mp_image_make_writeable mp_image_setrefp mp_image_to_av_frame_and_unref mp_image_from_av_frame mp_image_new_external_ref mp_image_new_custom_ref mp_image_pool_make_writeable mp_image_pool_get mp_image_pool_new_copy mp_vdpau_mixed_frame_create vf_alloc_out_image vf_make_out_image_writeable glGetWindowScreenshot
* options: remove OPT_FLAG_CONSTANTSwm42014-06-131-4/+4
| | | | | | | This means use of the min/max fields can be dropped for the flag option type, which makes some things slightly easier. I'm also not sure if the client API handled the case of flag not being 0 or 1 correctly, and this change gets rid of this concern.
* vd_lavc: use option parser for skip suboptionswm42014-06-131-22/+25
|
* vd_lavc: make option struct localwm42014-06-111-15/+34
| | | | | Removes specifics from options.h and options.c, and puts everything into vd_lavc.c.
* Add more constwm42014-06-111-1/+1
| | | | | | | While I'm not very fond of "const", it's important for declarations (it decides whether a symbol is emitted in a read-only or read/write section). Fix all these cases, so we have writeable global data only when we really need.
* vd_lavc: set video bitrate if availableMarcoen Hirschberg2014-05-281-0/+5
| | | | Set the bitrate of dec_video if it is available in avcodec.
* video: warn if an emulated hwdec API is usedwm42014-05-281-4/+9
| | | | | | | | | | | | | | | | mpv supports two hardware decoding APIs on Linux: vdpau and vaapi. Each of these has emulation wrappers. The wrappers are usually slower and have fewer features than their native opposites. In particular the libva vdpau driver is practically unmaintained. Check the vendor string and print a warning if emulation is detected. Checking vendor strings is a very stupid thing to do, but I find the thought of people using an emulated API for no reason worse. Also, make --hwdec=auto never use an API that is detected as emulated. This doesn't work quite right yet, because once one API is loaded, vo_opengl doesn't unload it, so no hardware decoding will be used if the first probed API (usually vdpau) is rejected. But good enough.
* video: add --video-rotate option for controlling auto-rotationwm42014-05-241-0/+7
|
* vd_lavc: Support hwaccel 1.2 and laterLuca Barbato2014-05-121-4/+4
| | | | | Hwaccel 1.2 populates only the third data field and assumes that the AVCodecContext is available to the dealloc function.
* video: add a "hwdec" property to enable or disable hw decoding at runtimewm42014-04-231-0/+9
|
* demux: export video rotation parameterwm42014-04-211-0/+1
| | | | | Now the rotation hint is propagated everywhere. It just isn't used anywhere yet.
* vd_lavc: reinit hwdec on profile changeswm42014-03-171-2/+5
| | | | | Needed in theory. I don't know if there are even any real-world files which change the profile mid-stream.
* vd_lavc: remove unused fieldwm42014-03-161-2/+0
|
* vd_lavc: reduce hardware decoder mid-stream reinitializationswm42014-03-161-1/+6
| | | | | | | | | | Instead of doing it on every seek (libavcodec calls get_format on every seek), reinitialize the decoder only if the video resolution changes. Note that this may be relatively naive, since we e.g. (or: in particular) don't check for profile changes. But it's not worse than the state before the get_format change, and at least it paints over the current vaapi breakage (issue #646).
* vd_lavc: remove compatibility crapwm42014-03-161-185/+21
| | | | | | | All this code was needed for compatibility with very old libavcodec versions only (such as Libav 9). Includes some now-possible simplifications too.
* vd_lavc: ridiculous workaround for Libav 9 compatibilitywm42014-03-161-1/+12
| | | | | | | | This "sometimes" crashed when seeking. The fault apparently lies in libavcodec: the decoder returns an unreferenced frame! This is completely insane, but somehow I'm apparently still expected to work this around. As a reaction, I will drop Libav 9 support in the next commit. (While this commit will go into release/0.3.)
* video: initialize hw decoder in get_formatwm42014-03-101-2/+20
| | | | | | | | | | | | | | | | Apparently the "right" place to initialize the hardware decoder is in the libavcodec get_format callback. This doesn't change vda.c and vdpau_old.c, because I don't have OSX, and vdpau_old.c is probably going to be removed soon (if Libav ever manages to release Libav 10). So for now the init_decoder callback added with this commit is optional. This also means vdpau.c and vaapi.c don't have to manage and check the image parameters anymore. This change is probably needed for when libavcodec VDA supports gets a new iteration of its API.
* vd_lavc: matroska: remove weird code setting extra_huff for mjpegwm42014-01-111-12/+0
| | | | | | | | | | | Like with the previous commit, this is probably not needed, but it's unclear whether that really is the case. Most likely, it used to be needed by some demuxer, and now the only demuxer left that could _possibly_ trigger this is demux_mkv.c. Note that mjpeg is the only decoder that reads the extra_huff option, and nothing in libavformat actually sets the option. So maybe it's fundamentally not needed anymore.
* vd_lavc: matroska: remove weird realvideo special handlingwm42014-01-111-16/+1
| | | | | | | | | | | | | This case can't happen with the normal realvideo codepath in demux_mkv.c, because the code would errors out if the extradata is too small, and everything would be broken anyway in the case the vd_lavc.c condition is actually triggered. It still might happen with VfW-muxed realvideo in Matroska, though. Basically, I'm hoping this doesn't matter anyway, and that the vd_lavc.c code was for other old demuxers, like demux_avi or demux_rm. Following the commit history, it's not really clear for what demuxer this code was added.
* vd_lavc: minor simplificationwm42014-01-111-11/+2
|
* Factor out setting AVCodecContext extradatawm42014-01-111-19/+8
|
* vd_lavc: by default, output all frames, even corrupted oneswm42013-12-291-0/+10
| | | | | | | | | | | | | | | | Set the flag CODEC_FLAG_OUTPUT_CORRUPT by default. Note that there is also CODEC_FLAG2_SHOW_ALL, which is older, but this seems to be ffmpeg only. Note that whether you want this enabled depends on the user. Some might prefer that only good frames are output, while others want the decoder to try as hard as possible to output _anything_. Since mplayer/mpv is rather the kind of player that tries hard instead of being "clever", set the new default to override libavcodec's default. A nice way to test this is switching video tracks. Since mpv doesn't wait for the next key frame, it'll start feeding the decoder with a packet from the middle of the stream.
* video/decode: mp_msg conversionswm42013-12-211-26/+32
| | | | Doesn't cover vdpau/vaapi parts yet, because these are a bit messier.
* Split mpvcore/ into common/, misc/, bstr/wm42013-12-171-5/+5
|
* Move options/config related files from mpvcore/ to options/wm42013-12-171-2/+2
| | | | | | | | | Since m_option.h and options.h are extremely often included, a lot of files have to be changed. Moving path.c/h to options/ is a bit questionable, but since this is mainly about access to config files (which are also handled in options/), it's probably ok.
* Replace mp_tmsg, mp_dbg -> mp_msg, remove mp_gtext(), remove set_osd_tmsgwm42013-12-161-11/+11
| | | | | | | | | The tmsg stuff was for the internal gettext() based translation system, which nobody ever attempted to use and thus was removed. mp_gtext() and set_osd_tmsg() were also for this. mp_dbg was once enabled in debug mode only, but since we have log level for enabling debug messages, it seems utterly useless.
* video: move video filter chain initialization from decoder to playerwm42013-12-101-43/+27
| | | | | | | | | | | | | This should help fixing some issues (like not draining video frames correctly on reinit), as well as decoupling the decoder, filter chain, and VO code. I also wanted to make the hardware video decoding fallback work properly if software-only video filters are inserted. This currently has the issue that the fallback is too violent, and throws away a bunch of demuxer packets needed to restart software decoding properly. But keeping "backup" packets turned out as too hacky, so I'm not doing this, at least not yet.
* video: create a separate context for video filter chainwm42013-12-071-2/+2
| | | | | | This adds vf_chain, which unlike vf_instance refers to the filter chain as a whole. This makes the filter API less awkward, and will allow handling format negotiation better.
* vd_lavc: factor out libavcodec thread setupwm42013-12-041-15/+1
|
* vd_lavc: don't check required hwdec fieldswm42013-12-041-4/+3
|
* av_common: add timebase parameter to mp_set_av_packet()wm42013-12-041-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | If the timebase is set, it's used for converting the packet timestamps. Otherwise, the previous method of reinterpret-casting the mpv style double timestamps to libavcodec style int64_t timestamps is used. Also replace the kind of awkward mp_get_av_frame_pkt_ts() function by mp_pts_from_av(), which simply converts timestamps in a way the old function did. (Plus it takes a timebase parameter, similar to the addition to mp_set_av_packet().) Note that this should not change anything yet. The code in ad_lavc.c and vd_lavc.c passes NULL for the timebase parameters. We could set AVCodecContext.pkt_timebase and use that if we want to give libavcodec "proper" timestamps. This could be important for ad_lavc.c: some codecs (opus, probably mp3 and aac too) have weird requirements about doing decoding preroll on the container level, and thus require adjusting the audio start timestamps in some cases. libavcodec doesn't tell us how much was skipped, so we either get shifted timestamps (by the length of the skipped data), or we give it proper timestamps. (Note: libavcodec interprets or changes timestamps only if pkt_timebase is set, which by default it is not.) This would require selecting a timebase though, so I feel uncomfortable with the idea. At least this change paves the way, and will allow some testing.
* Take care of some libavutil deprecations, drop support for FFmpeg 1.0wm42013-11-291-8/+8
| | | | | | | | | | | | | | PIX_FMT_* -> AV_PIX_FMT_* (except some pixdesc constants) enum PixelFormat -> enum AVPixelFormat Losen some version checks in certain newer pixel formats. av_pix_fmt_descriptors -> av_pix_fmt_desc_get This removes support for FFmpeg 1.0.x, which is even older than Libav 9.x. Support for it probably was already broken, and its libswresample was rejected by our build system anyway because it's broken. Mostly untested; it does compile with Libav 9.9.
* video: refactor PTS code, add fall back heuristic to DTSwm42013-11-271-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Refactor the PTS handling code to make it cleaner, and to separate the bits that use PTS sorting. Add a heuristic to fall back to DTS if the PTS us non-monotonic. This code is based on what FFmpeg/Libav use for ffplay/avplay and also best_effort_timestamp (which is only in FFmpeg). Basically, this 1. just uses the DTS if PTS is unset, and 2. ignores PTS entirely if PTS is non- monotonic, but DTS is sorted. The code is pretty much the same as in Libav [1]. I'm not sure if all of it is really needed, or if it does more than what the paragraph above mentions. But maybe it's fine to cargo-cult this. This heuristic fixes playback of mpeg4 in ogm, which returns packets with PTS==DTS, even though the PTS timestamps should follow codec reordering. This is probably a libavformat demuxer bug, but good luck trying to fix it. The way vd_lavc.c returns the frame PTS and DTS to dec_video.c is a bit inelegant, but maybe better than trying to mess the PTS back into the decoder callback again. [1] https://git.libav.org/?p=libav.git;a=blob;f=cmdutils.c;h=3f1c667075724c5cde69d840ed5ed7d992898334;hb=fa515c2088e1d082d45741bbd5c05e13b0500804#l1431
* cosmetics: rename video/audio reset functionswm42013-11-271-1/+1
| | | | | | | | | | These used the suffix _resync_stream, which is a bit misleading. Nothing gets "resynchronized", they really just reset state. (Some audio decoders actually used to "resync" by reading packets for resuming playback, but that's not the case anymore.) Also move the function in dec_video.c to the top of the file.
* demux: export dts from demux_lavf, use it for aviwm42013-11-251-4/+1
| | | | | | | | | Having the DTS directly can be useful for restoring PTS values. The avi file format doesn't actually store PTS values, just DTS. An older hack explicitly exported the DTS as PTS (ignoring the [I assume] genpts generated non-sense PTS), which is not necessary anymore due to this change.
* video: pass PTS as part of demux_packet/AVPacket and mp_image/AVFramewm42013-11-251-11/+11
| | | | | | | | | | | | | | | Instead of passing the PTS as separate field, pass it as part of the usual data structures. Basically, this removes strange artifacts from the API. (It's not finished, though: the final decoded PTS goes through strange paths, and filter_video() finally overwrites the decoded mp_image's pts field with it.) We also stop using libavcodec's reordered_opaque fields, and use AVPacket.pts and AVFrame.pkt_pts. This is slightly unorthodox, because these pts fields are not "really" opaque anymore, yet we treat them as such. But the end result should be the same, and reordered_opaque is marked as partially deprecated (it's not clear whether it's really deprecated).
* vd_lavc: improve a commentwm42013-11-241-1/+2
|
* vd_lavc: when falling back to software, revert filter error statuswm42013-11-231-0/+2
| | | | | | | | | | | | | | | | | | | When mpv is started with some video filters set (--vf is used), and hardware decoding is requested, and hardware decoding would be possible, but is prevented due to video filters that accept software formats only, the fallback didn't work properly sometimes. This fallback works rather violently: it tries to initialize the filter chain, and if it fails it throws away the frame decoded using the hardware, and retries with software. The case that didn't work was when decoding the current packet didn't immediately lead to a new frame. Then the filter chain wouldn't be reinitialized, and the playloop would stop playback as soon as it encounters the error flag. Fix this by resetting the filter error flag (back to "uninitialized"), which is a rather violent, but somewhat working solution. The fallback in general should perhaps be cleaned up later.
* video: move handling of container vs. stream AR out of vd_lavc.cwm42013-11-231-36/+17
| | | | | | | Now the actual decoder doesn't need to care about this anymore, and it's handled in generic code instead. This simplifies vd_lavc.c, and in particular we don't need to detect format changes in the old way anymore.
* dec_video: make vf_input and hwdec_info statically allocatedwm42013-11-231-2/+2
| | | | | | | | | | | The only reason why these structs were dynamically allocated was to avoid recursive includes in stheader.h, which is (or was) a very central file included by almost all other files. (If a struct is referenced via a pointer type only, it can be forward referenced, and the definition of the struct is not needed.) Now that they're out of stheader.h, this difference doesn't matter anymore, and the code can be simplified. Also sneak in some sanity checks.
* demux: remove gsh field from sh_audio/sh_video/sh_subwm42013-11-231-3/+3
| | | | | | | | | This used to be needed to access the generic stream header from the specific headers, which in turn was needed because the decoders had access only to the specific headers. This is not the case anymore, so this can finally be removed again. Also move the "format" field from the specific headers to sh_stream.
* video: move decoder context from sh_video into new structwm42013-11-231-72/+71
| | | | | | | | | |