summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
* vf: remove unneeded fieldwm42013-12-041-1/+0
| | | | | This was once required for padding, because many filters didn't use designated initializers, and initialized a removed field with NULL.
* vf_pullup: change options, reroute to vf_lavfiwm42013-12-041-10/+37
| | | | The options are probably mostly backwards compatible.
* vf_unsharp: change options, reroute to vf_lavfiwm42013-12-041-50/+37
|
* vf_phase: change options, reroute to vf_lavfiwm42013-12-041-35/+48
| | | | The option change is probably backwards compatible.
* vf_noise: reroute to vf_lavfiwm42013-12-041-26/+42
| | | | | | | | Unfortunately, this forces filtering both luma and chroma, because otherwise we'd have to deal with libavfilter's vf_noise weird handling of YUV vs. RGB formats. Would we e.g. filter luma only, it would filter red in RGB mode only, because it goes by component and there's no way to distinguish YUV and RGB by just using the filter's options.
* vf_stereo3d: reroute to vf_lavfiwm42013-12-041-10/+31
|
* vf_hqdn3d: change options, reroute to vf_lavfiwm42013-12-041-67/+34
|
* vf_gradfun: reroute to vf_lavfiwm42013-12-041-0/+23
| | | | | Also update the manpage. We changed defaults and added a suboption quite some time ago, and we forgot to update the manpage at all.
* vf_delogo: reroute to vf_lavfiwm42013-12-041-2/+20
| | | | The ``file`` suboption is unsupported on lavfi.
* vf_yadif: change options, reroute to vf_lavfiwm42013-12-041-15/+24
| | | | | | Also remove the ability to disable deinterlacing at runtime. You can still disable deinterlacing at runtime by using the ``D`` key and its automatical filter insertion/removal.
* vf_lavfi: export a wrapper functionwm42013-12-042-6/+156
| | | | | | | | | | | This will allow old filter to run libavfilter instead by calling vf_lw_set_graph(), which turns the filter into a wrapper, using a given libavfilter graph. Later commits use that to automatically "reroute" a bunch of filters to libavfilter. We want to get rid of the old MPlayer filter code, because it's bad an unmaintained, but we still don't want to force everyone to use vf_lavfi, so this solution will do for a while.
* video: remove VFCAP_POSTPROCwm42013-12-042-7/+1
| | | | This wasn't used anymore, not even until recently.
* vf_screenshot: remove unnecessary codewm42013-12-041-5/+0
|
* gl_video: change internal API for hwdec mp_image downloadStefano Pigozzi2013-12-023-10/+13
| | | | | | Previous API worked under the assumption that download_image is always called after map_image. In practice this is true, but it's better to have a much generic API that doesn't depend on the order in which the functions are called.
* gl_video: use hwdec download_image call only if hwdec is activewm42013-12-021-2/+3
| | | | | | | | | | The hwdec driver can be loaded, even if it's not used (e.g. when playing a file with no hardware decoding after one with it enabled). Also, check whether dlimage is NULL. Since this will do call into the native hwdec API, there's a chance a driver could fail doing this, it's better to check the return value, even if this case currently can't happen.
* options: add option to disable using right Alt key as Alt GrVivek Jain2013-12-022-4/+6
| | | | | | | | | mpv was hardcoded to always consider the right Alt key as Alt Gr, but there are parituclar combinations of platforms and keyboard layouts where it's more convenient to treat the right Alt as a keyboard modifier just like the left one. Fixes #388
* vo_opengl: support for vda hardware decodingStefano Pigozzi2013-12-025-0/+161
| | | | | | | | | | | The harder work was done in the previous commits. After that this feature comes out almost for free. The only problem is I can't get the textures created with CGLTexImageIOSurface2D to download properly, thus the code performs download using some CoreVideo APIs. If someone knows why download of textures created with CGLTexImageIOSurface2D doesn't work please contact me :)
* gl_video: support packed YUV formats with Apple extensionsStefano Pigozzi2013-12-024-2/+47
| | | | | | | | | | This adds support for packed YUV formats (YUVY and UYVY) using the extension GL_APPLE_rgb_422. While supporting this formats on their own is not that important (considering most video is planar YUV) they are used for interoperability with IOSurfaces. Next commit will use this formats to render VDA hardware decoded frames through IOSurface and OpenGL interoperability.
* vo_opengl: add support for rectangle textureswm42013-12-015-44/+86
| | | | | | | | | This allows vo_opengl to use GL_TEXTURE_RECTANGLE textures, either by enabling it with the 'rectangle-textures' sub-option, or by having a hwdec backend force it. By default it's off. The _only_ reason we're adding this is because VDA can export rectangle textures only.
* mp_image: deal with FFmpeg PSEUDOPAL braindeathwm42013-12-013-3/+15
| | | | | | | | | | We got a crash in libavutil when encoding with Y8 (GRAY8). The reason was that libavutil was copying an Y8 image allocated by us, and expected a palette. This is because GRAY8 is a PSEUDOPAL format. It's not clear what PSEUDOPAL means, and it makes literally no sense at all. However, it does expect a palette allocated for some formats that are not paletted, and libavutil crashed when trying to access the non-existent palette.
* vo_null: don't reject hwaccel formatswm42013-12-011-2/+0
| | | | | | This is not strictly needed anymore. (On the other hand, it's not really possible to do hw decoding with vo_null, because the VO is still responsible for opening the hw decoder API, but that's another story.)
* options: add options that set defaults for af/vf/ao/vowm42013-12-012-0/+4
| | | | | | | | There are some use cases for this. For example, you can use it to set defaults of automatically inserted filters (like af_lavrresample). It's also useful if you have a non-trivial VO configuration, and want to use --vo to quickly change between the drivers without repeating the whole configuration in the --vo argument.
* Take care of some libavutil deprecations, drop support for FFmpeg 1.0wm42013-11-298-158/+156
| | | | | | | | | | | | | | 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.
* vf_pullup: properly reset on seekwm42013-11-291-14/+37
| | | | | | | Sometimes, vf_pullup hanged on seek. This was because it never was properly reset. Old timestamps messed up the timestamp calculations, which made the player show frames for a ridiculously long time, which is perceived as pausing or hanging.
* gl_hwdec: use a imgfmt field instead of a query_format callbackwm42013-11-294-15/+5
| | | | | Now that vdpau always uses a single image format, this can be simplified.
* vdpau: always let decoder output IMGFMT_VDPAUwm42013-11-293-3/+4
| | | | | | | | | | The old ffmpeg vdpau support code uses separate vdpau pixel formats for each decoder (pretty much because mplayer's architecture sucked), which just gets into the way. Force the old decoder's output to IMGFMT_VDPAU, and remove IMGFMT_IS_VDPAU() where we can remove it. This should completely remove the differences betwene the old and new vdpau decoder outside of the decoder.
* vaapi: remove unused hw image formats, simplifywm42013-11-297-26/+11
| | | | | | | | | | PIX_FMT_VDA_VLD and PIX_FMT_VAAPI_VLD were never used anywhere. I'm not sure why they were even added, and they sound like they are just for compatibility with XvMC-style decoding, which sucks anyway. Now that there's only a single vaapi format, remove the IMGFMT_IS_VAAPI() macro. Also get rid of IMGFMT_IS_VDA(), which was unused.
* build: make pthreads mandatorywm42013-11-283-21/+5
| | | | | | | | | | | pthreads should be available anywhere. Even if not, for environment without threads a pthread wrapper could be provided that can't actually start threads, thus disabling features that require threads. Make pthreads mandatory in order to simplify build dependencies and to reduce ifdeffery. (Admittedly, there wasn't much complexity, but maybe we will use pthreads more in the future, and then it'd become a real bother.)
* video: add insane hack to work around FFmpeg/Libav insanitywm42013-11-281-3/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | So, FFmpeg/Libav requires us to figure out video timestamps ourselves (see last 10 commits or so), but the methods it provides for this aren't even sufficient. In particular, everything that uses AVI-style DTS (avi, vfw-muxed mkv, possibly mpeg4-in-ogm) with a codec that has an internal frame delay is broken. In this case, libavcodec will shift the packet- to-image correspondence by the codec delay, meaning that with a delay=1, the first AVFrame.pkt_dts is not 0, but that of the second packet. All timestamps will appear shifted. The start time (e.g. the time displayed when doing "mpv file.avi --pause") will not be exactly 0. (According to Libav developers, this is how it's supposed to work; just that the first DTS values are normally negative with formats that use DTS "properly". Who cares if it doesn't work at all with very common video formats? There's no indication that they'll fix this soon, either. An elegant workaround is missing too.) Add a hack to re-enable the old PTS code for AVI and vfw-muxed MKV. Since these timestamps are not reorderd, we wouldn't need to sort them, but it's less code this way (and possibly more robust, should a demuxer unexpectedly output PTS). The original intention of all the timestamp changes recently was actually to get rid of demuxer-specific hacks and the old timestamp sorting code, but it looks like this didn't work out. Yet another case where trying to replace native MPlayer functionality with FFmpeg/Libav led to disadvantages and bugs. (Note that the old PTS sorting code doesn't and can't handle frame dropping correctly, though.) Bug reports: https://trac.ffmpeg.org/ticket/3178 https://bugzilla.libav.org/show_bug.cgi?id=600
* video: warn against non-monotonic PTS instead of decreasing PTSwm42013-11-281-2/+2
| | | | And by non-monotonic, we mean "strictly non-monotonic".
* video: add heuristic to prevent framedrop during hrseek if pts brokenwm42013-11-282-0/+9
| | | | | | | | | | | | | | | | | | | | | | | Using --start with files that use DTS only, or which simply have broken PTS timestamps, would incorrectly drop frames and possibly not execute the seek correctly. Add yet another heuristic to detect this. The intent is that --start and hr-seeks in general should work correctly, but in order to keep things fast, we still want to allow frame dropping during hr-seek if there are no problems doing so. Do this by disabling frame dropping by default, but re-enabling it if there are no problems found for a while. As a consequence, --start might be somewhat slower, but normal user interaction should remain as fast as before. Note that there's something subtle about the added code: the has_broken_packet_pts field is checked even before the first packet is fed to dec_video.c, so the field must not be set to 0 right on start. It's not initially set to 0 anyway, because the heuristic requires decoding some images before enabling frame drop anyway. Note 2: it's not clear whether frame dropping during hr-seek really helps; I didn't benchmark it.
* video: replace d_video->pts field, change PTS jump checkswm42013-11-272-5/+6
| | | | | | | | | | | | | The d_video->pts field was a bit strange. The code overwrote it multiple times (on decoding, on filtering, then once again...), and it wasn't really clear what purpose this field had exactly. Replace it with the mpctx->video_next_pts field, which is relatively unambiguous. Move the decreasing PTS check to dec_video.c. This means it acts on decoder output, not on filter output. (Just like in the previous commit, assume the filter chain is sane.) Drop the jitter vs. reset semantics; the dec_video.c determined PTS never goes backwards, and demuxer timestamps don't "jitter".
* video: if PTS is missing, make something up using the frameratewm42013-11-271-3/+7
| | | | | | Also get rid of the PTS check _after_ filters. This means if there's a video filter which unsets PTS, no warning will be printed. But we assume that all filters are well-behaved enough by now.
* video: refactor PTS code, add fall back heuristic to DTSwm42013-11-273-70/+113
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Move some code from player to audio/video reset functionswm42013-11-271-0/+7
|
* cosmetics: rename video/audio reset functionswm42013-11-274-10/+10
| | | | | | | | | | 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.
* video: remove commented codewm42013-11-271-13/+2
|
* video: use dts as fallback when determining pts by sortingwm42013-11-271-11/+10
| | | | | This makes the new code equivalent with the old one, which often passed dts as pts. Also rename some variables to clear up things.
* video/filter: fix PIC compile on x86Natanael Copa2013-11-262-3/+9
| | | | | | | | | | | | | When using PIC on x86 (eg with hardened toolchains) the ebx register is reserverd and cannot be used in assembly code. For vf_eq we allow the compiler to use memory as input. For vf_noise we temoporarily borrow the ebp register. This fixes #361. Signed-off-by: Natanael Copa <ncopa@alpinelinux.org>
* video: unbreak --no-correct-pts with demuxers that use DTSwm42013-11-262-4/+6
|
* cocoa: unlock on uninitStefano Pigozzi2013-11-261-1/+3
| | | | NSLock should be unlocked before dealloc is called on it.
* video: move timestamp determination code to dec_videowm42013-11-252-0/+44
| | | | | | | | | | This means the code that tries to figure out the timestamp from demuxer and decoder output is now all in dec_video.c. We set the final timestamp on the returned image (mp_image.pts), as well as the d_video->pts field. The way the player uses d_video->pts field is still a bit messy. Maybe this could be cleaned up later.
* video: disable PTS sorting fallback by defaultwm42013-11-251-2/+3
| | | | | | | | | | | | | | | | It appears PTS sorting was useful only for avi files (and VfW-muxed mkv). Maybe it was historically also important for decoders with broken or non-existent PTS reordering (win32 codecs?). But now that we handle demuxers which outputs DTS only correctly, it just seems dead weight. Disable it by default. The --pts-association-mode option is now forced to always use the decoder's PTS value. You can still enable the old default (auto) or force sorting. But we will probably remove this option entirely at some point. Make demux_mkv export timestamps at DTS when it's in VfW mode. This is needed to get correct timestamps with the new default mode. demux_lavf already does that.
* 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.
* player: merge no-correct-pts with correct-pts codewm42013-11-252-0/+4
| | | | | | Now the --no-correct-pts mode is like the normal mode, just with different timestamp calculations. The semantics should be about the same as before this commit.
* player: change semantics of --no-correct-ptswm42013-11-251-1/+0
| | | | | | | | | | | | | Before this commit, this mode estimated the frame time by subtracting successive packet PTS values. This is complete non-sense for video codecs which use reordering. The code compensated frame times for these non-sense using the FPS value, but confused the rest of the player with non-sense jumping around timestamps. So, all in all this mode is not very useful. Repurpose this mode for fixed frame rate playback. This gives almost the same behavior as the old mode with forced framerate (--fps option). The result is simpler and often more robust.
* dec_video: fix function signaturewm42013-11-252-4/+6
| | | | Just why...? And why did this take 7 years?
* video: pass PTS as part of demux_packet/AVPacket and mp_image/AVFramewm42013-11-254-17/+22
| | | | | | | | | | | | | | | 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).
* osd: remove mp_osd_res.video_par fieldwm42013-11-247-8/+1
| | | | | | This is not needed anymore, because we decided that the PAR of the decoded video matters, and not the PAR of the filtered video that arrives at the VO.
* Rename sub.c/.h to osd.c/.hwm42013-11-2418-21/+16
| | | | | This was way too misleading. osd.c merely calls the subtitle renderers, instead of actually dealing with subtitles.
* 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.
* Attempt to fix build on older libavcodec versionswm42013-11-232-0/+2
|
* video: don't overwrite demuxer FPS valuewm42013-11-231-1/+1
| | | | | | | | | | | | | | | | If the --fps option was given (MPOpts->force_fps), the demuxer FPS value was overwritten with the forced value. This was fine, since the demuxer value wasn't needed anymore. But with the recent changes not to write to the demuxer stream headers, we don't want to do this anymore. So maintain the (forced/updated) FPS value in dec_video->fps. The removed code in loadfile.c is probably redundant, and an artifact from past refactorings. Note that sub.c will now always use the demuxer FPS value, instead of the user override value. I think this is fine, because it used the demuxer's video size values too. (And it's rare that these values are used at all.)
* video: move handling of container vs. stream AR out of vd_lavc.cwm42013-11-234-39/+34
| | | | | | | 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-233-7/+5
| | | | | | | | | | | 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.
* dec_video: remove "initialized" fieldwm42013-11-232-13/+8
| | | | It's redundant.
* 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 t