| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
| |
Remove VESA and FBDEV specific code that was forgotten when the
respective VOs were removed. Remove references to old or broken
stuff from example.conf.
|
| |
|
|
|
|
|
| |
This wasn't accessed anymore.
This is all what was left of mplayer2 commit c54fae82fd16
("vo: fix crash if all VO open fallback attempts fail").
|
| |
|
|
| |
This was a minor memory leak with no real impact.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
While being able to play videos on a framebuffer device would be nice,
I didn't need it, and couldn't even test it (buggy nvidia binary
drivers that disable framebuffers, buggy DirectFB that crashes when
using the X11 backend). It's just dead weight, get rid of it.
vo_directx was very horrible, and by today it's mostly useless. I didn't
remove it, because there was that-guy who told me in amazement how
awesome mplayer was, because it was the only video player fast enough
for fast playback on his system when using vo_directx. Sorry, that-guy.
|
| |
|
|
|
|
|
|
| |
init_best_video_out() did not manage the memory for vo->window_title
correctly, and free'd it twice when initialization failed (that's due
to talloc_free_children() being called). When the next VO was tried,
it reused the dangling pointer. Initialize this member somewhere else
lazily instead.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since slave mode is not planned to be kept, this VO is useless and I'm
removing it.
This VO was useful for OSX GUIs. Since in cocoa you can't embed views in
windows from other processes, this VO was writing to a sharedbuffer with
mmap. The OSX GUIs would then read from the buffer and render the image
with an external renderer.
If in the future we will want to support GUIs we will need to reasearch the
IOSurface framework. This allows to share kernel managed image data
across processes and integrates well with OpenGL.
|
| |
|
|
|
|
|
| |
This transition to a new VO API started over 4 years ago. It's time to
finally end it, and get rid of the horrible hacks.
Also removes some previously undetected dead code from spudec.c.
|
| |
|
|
|
|
|
|
|
|
|
| |
The removed VO and AO took MPEG data and decoded it with V4L2. I'm not
exactly sure what's the use of this today, but get rid of it.
As far as feeding video data to V4L2 is concerned, there are other
ways. For example, there is this script, that feeds yuv4mpeg formatted
raw video data to V4L2:
https://raw.github.com/umlaeute/v4l2loopback/master/examples/yuv4mpeg_to_v4l2.c
|
| |
|
|
|
|
|
|
| |
The encoding branch by divverent can handle of these via libavformat.
Note: for some reason, libav/ffmpeg have a GIF muxer only, and no
demuxer. The gif configure checks needef for the mplayer internal gif
demuxer can't be removed yet.
|
| |
|
|
| |
All of these have been replaced by vo_image.
|
| |
|
|
| |
This is supposed to replace vo_png and others.
|
| | |
|
| |
|
|
|
| |
Also change m_config_simple() such that you need to register options
using m_config_register_options().
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 48f0692ab9 "options: make option struct the talloc parent of options".
This made things actually more complicated. It introduced a new
parameter to the option parse and copy functions, which was used
inconsistently. Some code passed a parent, some not. Morever, you have
to call m_option_free() anyway, because not all options actually
respect the talloc parent. There is also the question whether passing
NULL as parent is supposed to work, or if you still have to implement
m_config_free().
On the other hand, this simplifies nothing. I assume the intention was
being able to free all option values with a single talloc_free() call,
but the same goal can be reached by simply freeing the m_config struct.
(The m_config talloc destructor will free each option values.)
Get rid of the talloc parent context parameter. This essentially
reverts commit 48f0692ab9 ("options: make option struct the talloc parent of options").
In video_out.c, make the VO priv struct the talloc parent for the
m_config object, so that destroying the VO will free the options.
The ability to free the m_config struct and all its managed options was
introduced in commit 89a17bcda6c.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This is about the vo_x11_init_state() call. It basically opens a X11
connection. It's called in the main() function once. It's not really
clear why this isn't done on VO creation instead. Maybe one reason was
that --no-fixed-vo used to be the default: when playing a new file, the
full VO state would be free'd and recreated. Keeping the X11 connection
possibly improved things, although the question is how. In summary,
there is no good reason to do this, and it only adds platform specific
details to the player frontend.
Do the X11 initialization in the respective VOs instead.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was disabled by default, and could be enabled with -dr. It was
disabled by default because it was buggy: there were issues with OSD
corruption.
It wasn't entirely sane for OpenGL based VOs either. OpenGL can chose
to drop mapped pixel buffer objects, requiring the application to map
and fill the buffer again. But there was no mechanism in mplayer to
fill the lost buffer again. (It seems this rarely happened in practice,
though.)
On the other side, users liked the --dr flag, because it promised them
more speed. I'm not sure if it actually helped with speed, but it's
unlikely it had any real advantages on modern systems.
In order to evade the --dr cargo culting in mplayer config files, it's
best to get rid of it.
|
| |
|
|
|
|
|
|
|
| |
The --title option, which sets the GUI window caption, is now expanded
as slave mode property string (like osd_show_property_text). Make the
default value for --title include the filename. This makes a behavior
similar to --use-filename-title the default.
Remove the --use-filename-title option, as it's redundant now.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
- There is no playtree anymore. It's reduced to a simple list.
- Options are now always global. You can still have per-file options,
but these are optional and require special syntax.
- The slave command pt_step has been removed, and playlist_next
and playlist_prev added. (See etc/input.conf changes.)
This is a user visible incompatible change, and will break slave-mode
applications.
- The pt_clear slave command is renamed to playlist_clear.
- Playtree entries could have multiple files. This is not the case
anymore, and playlist entries have always exactly one entry. Whenever
something adds more than one file (like ASX playlists or dvd:// or
dvdnav:// on the command line), all files are added as separate
playlist entries.
Note that some of the changes are quite deep and violent. Expect
regressions.
The playlist parsing code in particular is of low quality. I didn't try
to improve it, and merely spent to least effort necessary to keep it
somehow working. (Especially ASX playlist handling.)
The playtree code was complicated and bloated. It was also barely used.
Most users don't even know that mplayer manages the playlist as tree,
or how to use it. The most obscure features was probably specifying a
tree on command line (with '{' and '}' to create/close tree nodes). It
filled the player code with complexity and confused users with weird
slave commands like pt_up.
Replace the playtree with a simple flat playlist. Playlist parsers that
actually return trees are changed to append all files to the playlist
pre-order.
It used to be the responsibility of the playtree code to change per-file
config options. Now this is done by the player core, and the playlist
code is free of such details.
Options are not per-file by default anymore. This was a very obscure and
complicated feature that confused even experienced users. Consider the
following command line:
mplayer file1.mkv file2.mkv --no-audio file3.mkv
This will disable the audio for file2.mkv only, because options are
per-file by default. To make the option affect all files, you're
supposed to put it before the first file.
This is bad, because normally you don't need per-file options. They are
very rarely needed, and the only reasonable use cases I can imagine are
use of the encode backend (mplayer encode branch), or for debugging. The
normal use case is made harder, and the feature is perceived as bug.
Even worse, correct usage is hard to explain for users.
Make all options global by default. The position of an option isn't
significant anymore (except for options that compensate each other,
consider --shuffle --no-shuffle).
One other important change is that no options are reset anymore if a
new file is started. If you change settings with slave mode commands,
they will not be changed by playing a new file. (Exceptions include
settings that are too file specific, like audio/subtitle stream
selection.)
There is still some need for per-file options. Debugging and encoding
are use cases that profit from per-file options. Per-file profiles (as
well as per-protocol and per-VO/AO options) need the implementation
related mechanisms to backup and restore options when the playback file
changes.
Simplify the save-slot stuff, which is possible because there is no
hierarchical play tree anymore. Now there's a simple backup field.
Add a way to specify per-file options on command line. Example:
mplayer f1.mkv -o0 --{ -o1 f2.mkv -o2 f3.mkv --} f4.mkv -o3
will have the following options per file set:
f1.mkv, f4.mkv: -o0 -o3
f2.mkv, f3.mkv: -o0 -o3 -o1 -o2
The options --{ and --} start and end per-file options. All files inside
the { } will be affected by the options equally (similar to how global
options and multiple files are handled). When playback of a file starts,
the per-file options are set according to the command line. When
playback ends, the per-file options are restored to the values when
playback started.
|
| |
|
|
|
|
|
|
|
| |
Both VOs will now by default try to set vsync according to the global
vsync setting. By default, vsync is enabled, and passing --no-vsync will
disable it.
The --vsync option used to matter for vo_vesa only, but that VO has been
removed.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some of these have only limited use, and some of these have no use at
all. Remove them. They make maintainance harder and nobody needs them.
It's possible that many of the removed drivers were very useful a dozen
of years ago, but now it's 2012.
Note that some of these could be added back, in case they were more
useful than I thought. But right now, they are just a burden.
Reason for removal for each module:
vo_3dfx, vo_dfbmga, vo_dxr3, vo_ivtv, vo_mga, vo_s3fb,
vo_tdfxfb, vo_xmga, vo_tdfx_vid:
All of these are for very specific and outdated hardware. Some
of them require non-standard kernel drivers or do direct HW
access.
vo_dga: the most crappy and ancient way to get fast output on X.
vo_aa: there's vo_caca for the same purpose.
vo_ggi: this never lived, and is entirely useless.
vo_mpegpes: for DVB cards, I can't test this and it's crappy.
vo_fbdev, vo_fbdev2: there's vo_directfb2
vo_bl: what is this even? But it's neither important, nor alive.
vo_svga, vo_vesa: you want to use this? You can't be serious.
vo_wii: I can't test this, and who the hell uses this?
vo_xvr100: some Sun thing.
vo_xover: only useful in connection with xvr100.
ao_nas: still alive, but I doubt it has any meaning today.
ao_sun: Sun.
ao_win32: use ao_dsound or ao_portaudio instead.
ao_ivtv: removed along vo_ivtv.
Also get rid of anything SDL related. SDL 1.x is total crap for video
output, and will be replaced with SDL 2.x soon (perhaps), so if you
want to use SDL, write output drivers for SDL 2.x.
Additionally, I accidentally damaged Sun support, which made me
completely remove Sun/Solaris support. Nobody cares about this anyway.
Some left overs from previous commits removing modules were cleaned up.
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
.gitignore
bstr.c
cfg-mplayer.h
defaultopts.c
libvo/video_out.c
The conflict in bstr.c is due to uau adding a bstr_getline function in
commit 2ba8b91a97e7e8. This function already existed in this branch.
While uau's function is obviously derived from mine, it's incompatible.
His function preserves line breaks, while mine strips them. Add a
bstr_strip_linebreaks function, fix all other uses of bstr_getline, and
pick uau's implementation.
In .gitignore, change vo_gl3_shaders.h to use an absolute path
additional to resolving the merge conflict.
|
| | |
| |
| |
| |
| |
| | |
This video output is headless and only intended to work with GUIs
explicitly asking for it. This makes it useless to have it in the
autoprobe list.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Add infrastructure that allows VOs to specify the suboptions they
take, and get the values directly parsed into their private struct.
The option functionality available with the new system is the same as
for top-level player options. Convert vo_vdpau to use the new system
instead of the old subopt_helper.
|
| |\|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
bstr.c
bstr.h
libvo/cocoa_common.m
libvo/gl_common.c
libvo/video_out.c
mplayer.c
screenshot.c
sub/subassconvert.c
Merge of cocoa_common.m done by pigoz.
Picking my version of screenshot.c. The fix in commit aadf1002f8a will
be redone in a follow-up commit, as the original commit causes too many
conflicts with the work done locally in this branch, and other work in
progress.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This OSX video output is replaces the previous shared_buffer mode of
vo_corevideo. It manages a shared buffer and a Cocoa distributed
object to communicate with GUIs.
Splitting this code into a separate VO allows to get rid of harmful
code coupling, performance inefficiencies (useless image memory
copies) and ugly code (big if-else conditionals).
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
vo_gl will now fail at initialization if a software renderer is
detected. This is the same behavior as vo_gl_nosw. Making this the
default behavior is preferable, because it will simplify positioning
vo_gl in the VO autoprobe list (video_out_drivers[]). Also, vo_gl_nosw
exists only if X11 support is configured.
Move gl in place of gl_nosw. Add the "sw" suboption to vo_gl to allow
using vo_gl even if a software renderer is detected.
vo_gl_nosw is now completely equivalent to vo_gl. It is kept in order
not to break too many user configurations, but should be considered
deprecated.
|
| |\|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
bstr.c
bstr.h
etc/input.conf
input/input.c
input/input.h
libao2/ao_pulse.c
libmpcodecs/vf_ass.c
libmpcodecs/vf_vo.c
libvo/gl_common.c
libvo/x11_common.c
mixer.c
mixer.h
mplayer.c
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
The gl video output is faster and has more features than corevideo, so
it should be preferred on mac osx.
This doesn't affect GUI compatibility because they specify the
corevideo video output along with the suboptions for the shared buffer
name to mmap in.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
This video output is not useful anymore. It is based on Carbon to draw
the mplayer window and this has been deprecated by Apple in 10.5.
The upcoming 10.8 OSX release should deprecate most of Carbon, so it
doesn't make sense to keep vo_quartz in the codebase when there are
modern and better alternatives (vo_gl and vo_corevideo).
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Restructure parts of the code in the main play loop. The main
functionality difference is that if a video track ends first, now
audio will continue to be played until it ends too.
Now the process also wakes up less often if there's no need to update
video or audio. This will reduce unnecessary wakeups especially when
paused, but may make handling of input events laggier when fd-based
notifications are not supported (like most input on Windows).
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
This new vo is heavily based on vo_gl.c. It provides better scale
filters, dithering, and optional color management with LittleCMS2.
It requires OpenGL 3.
Many features are enabled by default, so it will be slower than vo_gl.
However, it can be tuned to behave almost as vo_gl.
|
| | |
| |
| |
| |
| | |
Since "direct3d" has broken color levels with some drivers, and there
is no simple fix for this, prefer "direct3d_shaders".
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Now using the "direct3d" VO will never make use of shaders. Instead, users
are supposed to use the direct3d_shaders VO entry, which is exactly the
same as direct3d, except with shaders enabled by default.
"direct3d" always uses the Direct3D StretcRect API call to render videos.
Playing formats not supported by this function will force mplayer to
insert a scale filter to convert video frames in software.
"direct3d_shaders" prefers shader color conversion, but can fall back to
StretchRect if the format can be handled. (This happens only with some
insignificant packed YUV formats.)
|
| | | |
|
| |\|
| |
| |
| |
| |
| | |
Conflicts:
mplayer.c
screenshot.c
|
| | |
| |
| |
| |
| |
| |
| |
| | |
vo_xv crashed if existing frames had been lost due to a config() call
in the middle of a file and vo_redraw_frame() was called. Add checks
to reject vo_redraw_frame() unless at least one frame has been flipped
after the the last configuration change, so individual VOs do not have
to deal with this case.
|
| |/
|
|
|
|
|
|
|
|
|
|
| |
The "backend" suboption allows selecting the GUI backend used by vo_gl.
Normally, it's auto-selected, but sometimes it's desireable to explicitly
select it.
Remove the gl_sdl VO. This can now be done by using: --vo=gl:backend=sdl
This is based on svn commit 34438, and tries to be compatible with it. The
undocumented numeric backend names serve this purpose. (They are
undocumented because names are preferred.)
|
| |
|
|
|
| |
Remove support for building the player without libavcodec and
libavformat. These libraries are now always required.
|
| |\ |
|
| | |
| |
| |
| |
| | |
Also change the WM_CLASS "application class" string from "MPlayer" to
"mplayer2". This string is visible as application name in Gnome 3.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This affects only the "new" VO API. The config() title argument was barely
used, and it's hardcoded to "MPlayer" in vf_vo.c. The X11 and the Cocoa
G |
