summaryrefslogtreecommitdiffstats
path: root/video/filter/vf_noise.c
Commit message (Collapse)AuthorAgeFilesLines
* video/filter: remove some vf_lavfi wrapperswm42015-09-111-71/+0
| | | | | | | | | | | | | | | | I see no point in keeping these around. Keeping wrappers for some select libavfilter filters just because MPlayer had these filters is not a good reason. Ultimately, all real filtering work should go to libavfilter, and users should get used to using vf_lavfi directly. We might even not require the awful double-nested syntax for using libavfilter one day. vf_rotate, vf_yadif, vf_stereo3d are kept because mpv uses them internally. (They all extend the lavfi filters or change their defaults.) vf_mirror is kept for symmetry with vf_flip. vf_gradfun and vf_pullup are probably semi-popular, so I'll remove them not yet - only after some more discussion.
* Update license headersMarcin Kurczewski2015-04-131-5/+4
| | | | Signed-off-by: wm4 <wm4@nowhere>
* vf_noise: remove internal implementationwm42015-02-111-239/+8
| | | | | It requires libavfilter now, just like many other filters. Not sure if it even makes sense to keep this wrapper.
* video: introduce failure path for image allocationswm42014-06-171-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* vf_noise: remove global variableswm42014-06-111-9/+4
|
* 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.
* Fix some libav* include statementswm42014-04-191-1/+2
| | | | | | | | | | | | | Fix all include statements of the form: #include "libav.../..." These come from MPlayer times, when FFmpeg was somehow part of the MPlayer build tree, and this form was needed to prefer the local files over system FFmpeg. In some cases, the include statement wasn't needed or could be replaced with mpv defined symbols.
* vf_noise: remove line asmwm42014-04-191-130/+4
| | | | | | | | I didn't test the speed, but by default, this filter diverts to libavfilter already. So this would help only if libavfilter is disabled, or libavfilter doesn't have vf_noise (like on Libav). For these cases, we still provide the (possibly but not necessarily) slower C implementation of vf_noise.
* Kill all tabswm42014-04-131-237/+237
| | | | | | | | | | | I hate tabs. This replaces all tabs in all source files with spaces. The only exception is old-makefile. The replacement was made by running the GNU coreutils "expand" command on every file. Since the replacement was automatic, it's possible that some formatting was destroyed (but perhaps only if it was assuming that the end of a tab does not correspond to aligning the end to multiples of 8 spaces).
* Split mpvcore/ into common/, misc/, bstr/wm42013-12-171-2/+2
|
* Move options/config related files from mpvcore/ to options/wm42013-12-171-1/+1
| | | | | | | | | 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.
* video/filter: remove vf_match_csp()wm42013-12-071-16/+1
| | | | | | | | | This function improves automatic filter insertion, but this really should be done by the generic filter code. Remove vf_match_csp() and all code using it as preparation for that. This commit temporarily makes handling of filter insertion worse for now, but it will be fixed with the following commits.
* video/filter: remove unneeded config callbackswm42013-12-051-8/+0
| | | | | | | | They didn't do anything. vf_screenshot.c actually did release the previous image, but that's not really required. At worst you could take a screenshot and get an old frame when there's no new frame yet.
* video/filter: fix some bogus free() callswm42013-12-051-3/+0
| | | | The generic filter code frees these; recent regression.
* vf_noise: reduce binary sizewm42013-12-041-4/+1
| | | | Same issues as in previous commit.
* video/filter: remove legacy option handling hackswm42013-12-041-1/+1
| | | | | | | | | All filters now either use the generic option parser, or don't have options. This finally finishes a transition started in 2003 (see git commit 33b62af94760186c). Why are MPlayer devs so monumentally lazy? Sorry, but this takes the cake. You had 10 years.
* 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.
* video/filter: fix PIC compile on x86Natanael Copa2013-11-261-2/+7
| | | | | | | | | | | | | 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>
* Fix some more -Wshadow warningswm42013-11-011-4/+4
| | | | | | These aren't printed with newer gcc or clang versions for some reason. All of them seem to be about local variables shadowing global functions.
* video/filter: remove useless vf_info fieldswm42013-10-231-6/+3
| | | | | This time I didn't bother to move the contents of the author field to the file headers. "git log" is your friend.
* core: move contents to mpvcore (2/2)Stefano Pigozzi2013-08-061-2/+2
| | | | Followup commit. Fixes all the files references.
* video: decouple internal pixel formats from FourCCswm42013-01-131-7/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | mplayer's video chain traditionally used FourCCs for pixel formats. For example, it used IMGFMT_YV12 for 4:2:0 YUV, which was defined to the string 'YV12' interpreted as unsigned int. Additionally, it used to encode information into the numeric values of some formats. The RGB formats had their bit depth and endian encoded into the least significant byte. Extended planar formats (420P10 etc.) had chroma shift, endian, and component bit depth encoded. (This has been removed in recent commits.) Replace the FourCC mess with a simple enum. Remove all the redundant formats like YV12/I420/IYUV. Replace some image format names by something more intuitive, most importantly IMGFMT_YV12 -> IMGFMT_420P. Add img_fourcc.h, which contains the old IDs for code that actually uses FourCCs. Change the way demuxers, that output raw video, identify the video format: they set either MP_FOURCC_RAWVIDEO or MP_FOURCC_IMGFMT to request the rawvideo decoder, and sh_video->imgfmt specifies the pixel format. Like the previous hack, this is supposed to avoid the need for a complete codecs.cfg entry per format, or other lookup tables. (Note that the RGB raw video FourCCs mostly rely on ffmpeg's mappings for NUT raw video, but this is still considered better than adding a raw video decoder - even if trivial, it would be full of annoying lookup tables.) The TV code has not been tested. Some corrective changes regarding endian and other image format flags creep in.
* video/filter: change filter API, use refcounting, remove filter DRwm42013-01-131-35/+11
| | | | | | | | | | | | | | | | | | | | Change the entire filter API to use reference counted images instead of vf_get_image(). Remove filter "direct rendering". This was useful for vf_expand and (in rare cases) vf_sub: DR allowed these filters to pass a cropped image to the filters before them. Then, on filtering, the image was "uncropped", so that black bars could be added around the image without copying. This means that in some cases, vf_expand will be slower (-vf gradfun,expand for example). Note that another form of DR used for in-place filters has been replaced by simpler logic. Instead of trying to do DR, filters can check if the image is writeable (with mp_image_is_writeable()), and do true in-place if that's the case. This affects filters like vf_gradfun and vf_sub. Everything has to support strides now. If something doesn't, making a copy of the image data is required.
* configure: remove check for .align semanticswm42013-01-131-3/+3
| | | | | | | | | | | | | | | | | | | | | The check determined whether the argument for .align is in bytes, or log2(bytes). Apparently it's always in bytes for ELF i386 systems, and this check is used for x86 inline assembler only. Even if this assumption should be wrong, it likely won't cause much damage: the existing code uses it only in the form ".align 4", which means in the worst case it will try to align to 16 bytes, which doesn't cause any problems (unless the object file format does not support such a high alignment). Update the filters that used this. Quoting the GNU as manual: For other systems, including ppc, i386 using a.out format, arm and strongarm, it is the number of low-order zero bits the location counter must have after advancement. For example `.align 3' advances the location counter until it a multiple of 8. If the location counter is already a multiple of 8, no change is needed.
* Rename directories, move files (step 2 of 2)wm42012-11-121-5/+5
| | | | | | | | | | | | Finish renaming directories and moving files. Adjust all include statements to make the previous commit compile. The two commits are separate, because git is bad at tracking renames and content changes at the same time. Also take this as an opportunity to remove the separation between "common" and "mplayer" sources in the Makefile. ("common" used to be shared between mplayer and mencoder.)
* Rename directories, move files (step 1 of 2) (does not compile)wm42012-11-121-0/+470
Tis drops the silly lib prefixes, and attempts to organize the tree in a more logical way. Make the top-level directory less cluttered as well. Renames the following directories: libaf -> audio/filter libao2 -> audio/out libvo -> video/out libmpdemux -> demux Split libmpcodecs: vf* -> video/filter vd*, dec_video.* -> video/decode mp_image*, img_format*, ... -> video/ ad*, dec_audio.* -> audio/decode libaf/format.* is moved to audio/ - this is similar to how mp_image.* is located in video/. Move most top-level .c/.h files to core. (talloc.c/.h is left on top- level, because it's external.) Park some of the more annoying files in compat/. Some of these are relicts from the time mplayer used ffmpeg internals. sub/ is not split, because it's too much of a mess (subtitle code is mixed with OSD display and rendering). Maybe the organization of core is not ideal: it mixes playback core (like mplayer.c) and utility helpers (like bstr.c/h). Should the need arise, the playback core will be moved somewhere else, while core contains all helper and common code.