| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
Reason: I never liked it being recursive. Generally, this seems to
cause more problems than trouble, and is less flexible for access
outside of the chain.
|
| |
|
|
|
|
| |
The vf_eq context contains a very large lookup table, and the method of
setting default values caused the vf_eq context to be included in the
compiled code.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
| |
This time I didn't bother to move the contents of the author field to
the file headers. "git log" is your friend.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Using -vf eq and changing brightness, contrast, etc. using key bindings
with e.g. "add brightness 1" didn't work well: with step width 1, the
property gets easily "stuck". This is a rounding problem: e.g. setting
gamma to 3 would actually make it report that gamma is set to 2, so
the "add" command will obviously never reach 3 with a step width of 1.
Fix this by storing the parameters as integers.
This was broken in cac7702. This commit effectively changed these
properties to use the value as reported by vf_eq, instead of the
previously set value for the "add" command. This was more robust,
but not very correct either, so we keep the new behavior and make
vf_eq report its parameters more accurately.
|
| |
|
|
| |
Followup commit. Fixes all the files references.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
vf_eq was deleted earlier, which makes the name vf_eq2 even more
awkward.
|
