| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For some reason, both m_config and m_struct are somewhat similar, except
that m_config is much more powerful. m_config is used for VOs and some
other things, so to unify them. We plan to kick out m_struct and use
m_config for everything. (Unfortunately, m_config is also a bit more
bloated, so this commit isn't all that great, but it will allow to
reduce the option parser mess somewhat.)
This commit also switches all video filters to use the option macros.
One reason is that m_struct and m_config, even though they both use
m_option, store the offsets of the option fields differently (sigh...),
meaning the options defined for either are incompatible. It's easier to
switch everything in one go.
This commit will allow using the -vf option parser for other things,
like VOs and AOs.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There was a MPOpts fullscreen field, a mp_vo_opts.fs field, and
VOFLAG_FULLSCREEN. Remove all these and introduce a
mp_vo_opts.fullscreen flag instead.
When VOs receive VOCTRL_FULLSCREEN, they are supposed to set the
current fullscreen mode to the state in mp_vo_opts.fullscreen. They
also should do this implicitly on config().
VOs which are capable of doing so can update the mp_vo_opts.fullscreen
if the actual fullscreen mode changes (e.g. if the user uses the
window manager controls). If fullscreen mode switching fails, they
can also set mp_vo_opts.fullscreen to the actual state.
Note that the X11 backend does almost none of this, and it has a
private fs flag to store the fullscreen flag, instead of getting it
from the WM. (Possibly because it has to deal with broken WMs.)
The fullscreen option has to be checked on config() to deal with
the -fs option, especially with something like:
mpv --fs file1.mkv --{ --no-fs file2.mkv --}
(It should start in fullscreen mode, but go to windowed mode when
playing file2.mkv.)
Wayland changes by: Alexander Preisinger <alexander.preisinger@gmail.com>
Cocoa changes by: Stefano Pigozzi <stefano.pigozzi@gmail.com>
|
| |
|
|
| |
Add libswscale includes where they are actually needed instead.
|
| | |
|
| |
|
|
|
|
|
|
| |
Image parameters like colorspace, color levels, and chroma location are
generally less important, and many filters don't set them correctly.
Force them instead in the generic VF code, which is probably better and
more convenient over all. So we designate this is a proper solution,
instead of a dirty hack.
|
| |
|
|
|
|
|
|
|
| |
libswscale doesn't seem to require this (anymore?), and libavfiltert's
vf_scale doesn't do it either. Moreover, this wasn't done for most other
subsampled formats, not even very old ones. So just remove it.
(It'd be quite easy to align on chroma boundaries with all pixel
formats, though.)
|
| |
|
|
|
|
|
|
|
| |
Until now, vf_scale only tried formats listed in the outfmt_list array.
Extend this and try every pixel format supported by mpv if trying
outfmt_list doesn't lead to success.
Also add some checks whether swscale really supports a given input or
output format. This was implicitly done with outfmt_list before.
|
| |
|
|
|
|
| |
ffmpeg's and the internal palette format used to have different
endianess, but that is not the case anymore. This code was forgotten
when that change was made.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of handling colorspaces with VFCTRLs/VOCTRLs, make them part of
the normal video format negotiation. The colorspace is passed down like
other video params with config/reconfig calls.
Forcing colorspaces (via the --colormatrix options and properties) is
handled differently too: if it's changed, completely reinit the video
chain. This is slower and requires a precise seek to the same position
to perform an update, but it's simpler and less bug-prone. Considering
switching the colorspace at runtime by user-interaction is a rather
obscure feature, this is a good change.
The colorspace VFCTRLs and VOCTRLs are still kept. The VOs rely on it,
and would have to be changed to get rid of them. We'll do that later,
and convert them incrementally instead of in one go.
Note that controlling the output range now always works on VO level.
Basically, this means you can't get vf_scale to output full-range YUV
for whatever reason. If that is really wanted, it should be a vf_scale
option. the previous behavior didn't make too much sense anyway.
This commit fixes a few bugs (such as playing RGB video and converting
that to YUV with vf_scale - a recent commit broke this and forced the
VO to display YUV as RGB if possible), and might introduce some new
ones.
|
| |
|
|
|
| |
Slightly cleaner, although rather redundant. But still, why wasn't this
added 10 years ago?
|
| |
|
|
| |
Didn't work on Windows. Apparently, WIN32 is not set in the Makefile.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use the video decoder chroma location flags and render chroma locations
other than centered. Until now, we've always used the intuitive and
obvious centered chroma location, but H.264 uses something else.
FFmpeg provides a small overview in libavcodec/avcodec.h:
-----------
/**
* X X 3 4 X X are luma samples,
* 1 2 1-6 are possible chroma positions
* X X 5 6 X 0 is undefined/unknown position
*/
enum AVChromaLocation{
AVCHROMA_LOC_UNSPECIFIED = 0,
AVCHROMA_LOC_LEFT = 1, ///< mpeg2/4, h264 default
AVCHROMA_LOC_CENTER = 2, ///< mpeg1, jpeg, h263
AVCHROMA_LOC_TOPLEFT = 3, ///< DV
AVCHROMA_LOC_TOP = 4,
AVCHROMA_LOC_BOTTOMLEFT = 5,
AVCHROMA_LOC_BOTTOM = 6,
AVCHROMA_LOC_NB , ///< Not part of ABI
};
-----------
The visual difference is literally minimal, but since videophiles
apparently consider this detail as quality mark of a video renderer,
support it anyway. We don't bother with chroma locations other than
centered and left, though.
Not sure about correctness, but it's probably ok.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The filter chain and the video ouputs have config() functions. They are
strictly limited to transfering the video size and format. Other
parameters (like color levels) have to be transferred separately.
Improve upon this by introducing a separate set of reconfig() functions,
which use mp_image_params to carry format parameters. This struct
contains all image format related parameters from config(), plus
additional parameters such as colorspace.
Change vf_rotate to use it, as well as vo_opengl. vf_rotate is just
an example/test case, but vo_opengl will need it later.
The intention is also to get rid of VOCTRL_SET_YUV_COLORSPACE. This
information is now handed to the VOs via reconfig(). The getter,
VOCTRL_GET_YUV_COLORSPACE, will still be needed though.
|
| | |
|
| | |
|
| |
|
|
|
| |
The filter analyzes each frame for combing, and decides at the end
whether the content is likely interlaced, telecined or progressive.
|
| |
|
|
|
|
|
|
|
| |
If the image is not writeable, the image actually has to be copied
beforehand. This was overlooked when converting the video chain to
reference counted images.
Fix a double free issue. This was overlooked when vf.c was changed to
free filter priv data automatically.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Can be used to refer to filters by name. Intended to be used when the
filter chain is changed at runtime.
A label can be assigned to a filter by prefixing it with '@name:', where
'name' is an user-chosen identifier. For example, a filter added with
'-vf-add @label1:gradfun=123' can be removed with '-vf-del @label1'.
If a filter with an already existing label is added, the existing filter
is replaced with the new filter (this happens for both -vf-add and
-vf-pre). If a filter is replaced, the new filter takes the position of
the old filter, instead of being appended/prepended to the filter chain
as usual. For -vf-toggle, labels are compared if at least one of the
filters has a label; otherwise they are compared by filter name and
arguments (like before). This means two filters are never considered
equal if one has a label and the other one does not.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
This happens only if an option actually allocates memory (like strings).
Change filter API such that vf->priv is free'd by vf.c instead by the
filters. vf.c will free the option values as well.
|
| |
|
|
|
|
|
|
| |
These were found by the cppcheck and scan-build static analyzers. Most
of these aren't interesting (the 2 previous commits fix some interesting
cases found by these analyzers), and they don't nearly fix all warnings.
(Most of the unfixed warnings are spam, things MPlayer never cared
about, or false positives.)
|
| |
|
|
| |
The original frame PTS was used instead. Oops...
|
| |
|
|
|
| |
Repurpose the 3 byte case for any unhandled pixel width. Fixes rotation
with e.g. rgb48. Very inefficient, but works.
|
| |
|
|
| |
Needed for the ffmpeg j2k decoder.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
libavfilter changed the way a format list is passed to vf_format. Now
you have to separate formats with "|" instead of ":". If you use "|",
it prints an annoying message on every reinit:
[format @ 0x8bbaaa0]This syntax is deprecated. Use '|' to separate the list items.
...and it will probably stop working without warning at some point in
the future.
We need some very annoying ifdeffery to detect this case, because
libavfilter version numbers are just plain incompatible between Libav
and ffmpeg. There is no other way to detect this.
(Sometimes I wonder whether ffmpeg and especially Libav actually like
causing unnecessary pain for their users, and intentionally break stuff
in the most annoying way possible. Sigh...)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Resetting the filter graph helps dealing with filters which save state
between frames. This is important especially if they modify frame timing
or emit additional frames.
Unfortunately the libavfilter API doesn't have a way to do this
directly, so we have to use a dirty trick: we recreate the whole graph,
including format negotiation down and filter string parsing. ffplay does
this too. If libavfilter somehow decides to change output format or size
from what the first run in config() returned, mpv will explode. The same
applies to vf_next_query_format() return values (although this could be
mitigated, should it really happen).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Requires recent FFmpeg/Libav git versions. Earlier versions will not
be supported, as the API is different. (A libavfilter version that
uses AVFrame instead of AVFilterBuffer is needed.)
Note that this is sort of useless, because the option parser prevents
you from making use of the full libavfilter graph syntax. This has to be
fixed later.
Most of the filter creation code (half of the config() function) has
been taken from avplay.c.
This code is not based on MPlayer's vf_lavfi. The MPlayer code doesn't
compile as it hasn't been updated through multiple libavfilter API
changes, making it completely useless as a starting point.
|
| |
|
|
|
|
| |
These filters incorrectly calculated the amount of bytes per line
in each plane for chroma subsampled formats, causing undefined
behavior.
|
| | |
|
| |
|
|
| |
The filter refuses to initialize if the video_out is NULL.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
VFCAP_OSD was used to determine at runtime whether the VO supports OSD
rendering. This was mostly unused. vo_direct3d had an option to disable
OSD (was supposed to allow to force auto-insertion of vf_ass, but we
removed that anyway). vo_opengl_old could disable OSD rendering when a
very old OpenGL version was detected, and had an option to explicitly
disable it as well.
Remove VFCAP_OSD from everything (and some associated logic). Now the
vo_driver.draw_osd callback can be set to NULL to indicate missing OSD
support (important so that vo_null etc. don't single-step on OSD
redraw), and if OSD support depends on runtime support, the VO's
draw_osd should just do nothing if OSD is not available.
Also, do not access vo->want_redraw directly. Change the want_redraw
reset logic for this purpose, too. (Probably unneeded, vo_flip_page
resets it already.)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allowed making the player switch the monitor video mode when
creating the video window. This was a questionable feature, and with
today's LCD screens certainly not useful anymore. Switching to a random
video mode (going by video width/height) doesn't sound too useful
either.
I'm not sure about the win32 implementation, but the X part had several
bugs. Even in mplayer-svn (where x11_common.c hasn't been receiving any
larger changes for a long time), this code is buggy and doesn't do the
right thing anyway. (And what the hell _did_ it do when using multiple
physical monitors?)
If you really want this, write a shell script that calls xrandr before
and after calling mpv.
vo_sdl still can do mode switching, because SDL has native support for
it, and using it is trivial. Add a new sub-option for this.
|
| |
|
|
| |
Commit 2e1063d changed the option parsing, and args is always NULL now.
|
| |
|
|
|
|
|
| |
And support the PIX_FMT_MONOWHITE pixel format. (This is really weird:
unlike PIX_FMT_MONOBLACK, it uses white pixels. I have no idea why
libavcodec doesn't just convert the pixel format on the fly, instead of
bothering everyone with really special pixel formats.)
|
| |
|
|
|
|
|
|
|
| |
Use the option parser instead of sscanf. Remove the parameter changing
the field dominance (it has been marked deprecated for ages). Add a new
suboption "enabled", which can be used to disable the filter by default,
until it's enabled at runtime:
mpv -vf yadif=enabled=no
|
| |
|
|
|
| |
This wasn't really useful, and the option preset mechanism is awfully
complex.
|
| |
|
|
| |
The code becomes amazingly simpler.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use codec names instead of FourCCs to identify codecs. Rewrite how
codecs are selected and initialized. Now each decoder exports a list
of decoders (and the codec it supports) via add_decoders(). The order
matters, and the first decoder for a given decoder is preferred over
the other decoders. E.g. all ad_mpg123 decoders are preferred over
ad_lavc, because it comes first in the mpcodecs_ad_drivers array.
Likewise, decoders within ad_lavc that are enumerated first by
libavcodec (using av_codec_next()) are preferred. (This is actually
critical to select h264 software decoding by default instead of vdpau.
libavcodec and ffmpeg/avconv use the same method to select decoders by
default, so we hope this is sane.)
The codec names follow libavcodec's codec names as defined by
AVCodecDescriptor.name (see libavcodec/codec_desc.c). Some decoders
have names different from the canonical codec name. The AVCodecDescriptor
API is relatively new, so we need a compatibility layer for older
libavcodec versions for codec names that are referenced internally,
and which are different from the decoder name. (Add a configure check
for that, because checking versions is getting way too messy.)
demux/codec_tags.c is generated from the former codecs.conf (minus
"special" decoders like vdpau, and excluding the mappings that are the
same as the mappings libavformat's exported RIFF tables). It contains
all the mappings from FourCCs to codec name. This is needed for
demux_mkv, demux_mpg, demux_avi and demux_asf. demux_lavf will set the
codec as determined by libavformat, while the other demuxers have to do
this on their own, using the mp_set_audio/video_codec_from_tag()
functions. Note that the sh_audio/video->format members don't uniquely
identify the codec anymore, and sh->codec takes over this role.
Replace the --ac/--vc/--afm/--vfm with new --vd/--ad options, which
provide cover the functionality of the removed switched.
Note: there's no CODECS_FLAG_FLIP flag anymore. This means some obscure
container/video combinations (e.g. the sample Film_200_zygo_pro.mov)
are played flipped. ffplay/avplay doesn't handle this properly either,
so we don't care and blame ffmeg/libav instead.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add more vf_stereo3d output formats.
Adds high quality green-magenta and yellow-blue dubois
anaglyph 3D output support.
Patch by thomas schorpp, thomas.schorpp gmail
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35906 b3059339-0415-0410-9bf9-f77b7e298cf2
Conflicts:
video/filter/vf_stereo3d.c
|
| |
|
|
|
| |
"yv12" stopped working a while ago, and so did other FourCC-like names.
Make "yv12" work again, so that the examples in TOOLS/vf_dlopen/ work.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Remove screenshot_force and associated logic. Always try to use the
screenshot video filter before trying taking screenshots with the VO,
which means that --vf=screenshot now takes the role of --vf=screenshot_force.
(To make this clear, not adding a video filter is still the recommended
way to take screenshots; we just change how VF screenshots are forced.)
Preferring VO over VF and having --vf=screenshot_force used to make
sense when not all VOs supported screenshots, and some VOs had somewhat
broken screenshots (like vo_xv taking screenshots with OSD in it). But
all these issues are fixed now, so just get rid of the cruft.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Now the calculations of the final display size are done after the filter
chain. This makes the difference between display aspect ratio and window
size a bit more clear, especially in the -xy case.
With an empty filter chain, the behavior of the options should be the
same, except that they don't affect vo_image and vo_lavc anymore.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Drop queued frames on seek. Reset the internal state of some filters
that seem to need it as well: at least vf_divtc still produced some
frames using the previous PTS.
This fixes weird behavior with some filters on seeking. In particular,
this could lead to A/V desync or apparent lockups due to the PTS of
filtered frames being too far away from audio PTS.
This commit does only the minimally required work to fix these PTS
related issues. Some filters have state dependent on previously filtered
frames, and these are not automatically reset with this commit (even
vf_divtc and vf_softpulldown reset the PTS info only). Filters that
actually require a full reset can implement VFCTRL_SEEK_RESET.
|
| |
|
|
|
| |
This failed with an assert, because the format of the format of the
output image was not set correctly.
|
| |
|
|
|
| |
Somewhat useful to see where filters are auto-inserted and which formats
they take.
|
| |
|
|
|
|
|
|
|
| |
In theory, vf_sub could take any format supported by swscale. But to be
sure that it's reasonably fast, only 420P was allowed. However, other
similar 8 bit planar formats will be just as fast and there's no reason
to exclude them. Even for completely different formats there doesn't
seem to be any significant advantage to force vf_sub to convert to a
simpler/more common format.
|
| |
|
|
|
