summaryrefslogtreecommitdiffstats
path: root/video/decode
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).
* 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 Haas2014-06-221-0/+2
| | | | Signed-off-by: wm4 <wm4@nowhere>
* 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.
* player: hide audio/video codec and file format messageswm42014-05-311-2/+1
| | | | | None of these are very important usually. For error analysis, the plain log is useless anyway, and this information is still printed with "-v".
* vd_lavc: set video bitrate if availableMarcoen Hirschberg2014-05-281-0/+5
| | | | Set the bitrate of dec_video if it is available in avcodec.
* audio: rename i_bps to 'bitrate' to avoid confusionMarcoen Hirschberg2014-05-282-3/+3
| | | | Since i_bps now contains bits/sec, rename it to reflect this change.
* audio: change values from bytes-per-second to bits-per-secondMarcoen Hirschberg2014-05-282-3/+3
| | | | | | | The i_bps members of the sh_audio and dev_video structs are mostly used for displaying the average audio and video bitrates. Keeping them in bits-per-second avoids truncating them to bytes-per-second and changing them back lateron.
* vaapi: fix destruction with --hwdec=haapi-copywm42014-05-281-2/+6
| | | | | | | This is incomplete; the video chain will still hold some vaapi objects after destroying the decoder and thus the vaapi context. This is very bad. Fixing it would require something like refcounting the vaapi context, but I don't really want to.
* video: warn if an emulated hwdec API is usedwm42014-05-284-4/+17
| | | | | | | | | | | | | | | | 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: better handling for (very) broken timestampswm42014-05-271-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Sometimes, Matroska files store monotonic PTS for h264 tracks with b-frames, which means the decoder actually returns non-monotonic PTS. Handle this with an evil trick: if DTS is missing, set it to the PTS. Then the existing logic, which deals with falling back to DTS if PTS is broken. Actually, this trick is not so evil at all, because usually, PTS has no errors, and DTS is either always set, or always unset. So this _should_ provoke no regressions (famous last words). libavformat actually does something similar: it derives DTS from PTS in ways unknown to me. The result is very broken, but it causes the DTS fallback to become active, and thus happens to work. Also, prevent the heuristic from being active if PTS is merely monotonic instead of strictly-monotonic. Non-unique PTS is broken, but we can't fallback to DTS anyway in these cases. The specific mkv file that is fixed with this commit had the following fields set: Muxing application: libebml v1.3.0 + libmatroska v1.4.1 Writing application: mkvmerge v6.7.0 ('Back to the Ground') [...] But I know that this should also fix playback of mencoder produced mkv files.
* video: add --video-rotate option for controlling auto-rotationwm42014-05-241-0/+7
|
* vdpau: don't fallback to software decoding on preemptionwm42014-05-181-7/+12
| | | | | This was requested by someone. Not sure if it's a good idea; it seems more can go wrong than right.
* vda: Hwaccel 1.2 supportLuca Barbato2014-05-121-34/+69
| | | | Use the new context and the default functions provided.
* vda: Simplify codec selectionLuca Barbato2014-05-121-28/+2
| | | | VDA supports h264 only.
* 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.
* vdpau: handle display preemption during decodingwm42014-05-101-38/+13
| | | | | | | | | | | | This was broken for some time, and it didn't recover correctly. Redo decoder display preemption. Instead of trying to reinitialize the hw decoder, simply fallback to software decoding. I consider display preemption a bug in the vdpau API, so being able to _somehow_ recover playback is good enough. The approach taking here will probably also make it easier to handle multithreading.
* options: remove deprecated --identifyMartin Herkt2014-05-041-1/+0
| | | | | | | Also remove MSGL_SMODE and friends. Note: The indent in options.rst was added to work around a bug in ReportLab that causes the PDF manual build to fail.
* video: change everythingwm42014-05-022-6/+2
| | | | | | | Change how the video decoding loop works. The structure should now be a bit easier to follow. The interactions on format changes are (probably) simpler. This also aligns the decoding loop with future planned changes, such as moving various things to separate threads.
* video: handle colorspace and aspect overrides separatelywm42014-05-021-2/+2
| | | | | Now the video filter code handles these explicitly, which should increase robustness (or at least find bugs earlier).
* video: improve error messageswm42014-04-301-1/+1
|
* video: add a "hwdec" property to enable or disable hw decoding at runtimewm42014-04-233-0/+11
|
* demux: export video rotation parameterwm42014-04-211-0/+1
| | | | | Now the rotation hint is propagated everywhere. It just isn't used anywhere yet.
* player: add a --dump-stats optionwm42014-04-171-1/+3
| | | | | | | | | | | | | | | | | | | | | | | This collects statistics and other things. The option dumps raw data into a file. A script to visualize this data is included too. Litter some of the player code with calls that generate these statistics. In general, this will be helpful to debug timing dependent issues, such as A/V sync problems. Normally, one could argue that this is the task of a real profiler, but then we'd have a hard time to include extra information like audio/video PTS differences. We could also just hardcode all statistics collection and processing in the player code, but then we'd end up with something like mplayer's status line, which was cluttered and required a centralized approach (i.e. getting the data to the status line; so it was all in mplayer.c). Some players can visualize such statistics on OSD, but that sounds even more complicated. So the approach added with this commit sounds sensible. The stats-conv.py script is rather primitive at the moment and its output is semi-ugly. It uses matplotlib, so it could probably be extended to do a lot, so it's not a dead-end.
* vdpau: remove pointer indirection for a fieldwm42014-03-191-3/+3
| | | | There's no reason to. This is basically a cosmetic change.
* vdpau: fix decoder init return valuewm42014-03-191-3/+3
|
* vaapi: make struct va_surface privatewm42014-03-171-11/+8
| | | | | | It's not really needed to be public. Other code can just use mp_image. The only disadvantage is that the other code needs to call an accessor to get the VASurfaceID.
* vaapi: replace image pool implementation with mp_image_poolwm42014-03-171-30/+29
| | | | | | | | | | | | Although I at first thought it would be better to have a separate implementation for hwaccels because the difference to software images are too large, it turns out you can actually save some code with it. Note that the old implementation had a small memory management bug. This got painted over in commit 269c1e1, but is hereby solved properly. Also note that I couldn't test vf_vavpp.c (due to lack of hardware), and I hope I didn't accidentally break it.
* vdpau: remove legacy pixel formatswm42014-03-171-1/+1
| | | | | | They were used by ancient libavcodec versions. This also removes the need to distinguish vdpau image formats at all (since there is only one), and some code can be simplified.
* vdpau: remove unused typewm42014-03-171-6/+0
|
* vd_lavc: reinit hwdec on profile changeswm42014-03-172-2/+6
| | | | | 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-162-3/+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-167-798/+28