Add a flags parameter to mp_input_set_section(). Add a flag that defines
whether bindings in the default section are used or not. This is useful
for special functionality, where the normal key bindings may have
unwanted effects.
For example, it shouldn't be possible to seek during encoding. However,
you want to be able to cancel the encoding process gracefully. For that
purpose, the "encode" section of input.conf could be made exclusive:
mp_input_set_section(mpctx->input, "encode", MP_INPUT_NO_DEFAULT_SECTION);
And input.conf could contain this definition:
RIGHT seek 10
q {encode} quit
Then only the key "q" would be bound during encoding.
If empty text is rendered, the bounding box is empty. Instead of
continuing with a bogus bounding box that would result in garbage
being rendered on screen, make the OSD image invisible.
This happened when playing demuxer SRT subtitles (e.g. SRT embedded in
MKV) with -no-ass at the moment a subtitle line disappeared.
Unrelated to this issue, fix libass API usage. Delete the event with
libass_flush_events(), instead of trying to reuse the previous event.
Based on a patch by uau.
The <libavutil/avutil.h> stopped including <libavutil/common.h>
recursively in recent ffmpeg/libav git revisions. As a result, some
files no longer got needed definitions, causing a build failure.
Modify #include lines in various files to fix build with the latest
versions of ffmpeg/libav headers.
If either of them is not defined, the old behavior is used:
- the colormatrix is guessed based on resolution.
- the color range is assumed to be tv aka limited range.
The functionality enabled with the --leak-report option is very useful
for debugging. Introduce a check for the MPLAYER_LEAK_REPORT environment
variable, and enable talloc leak report if it's set to "1".
The environment variable encourages enabling leak report permanently
during development. It's also a bit harder to get wrong: if the
--leak-report option is not the first option, it's silently ignored.
You can't put this option into a config file either. Enabling this
with --enable-debug in configure is not an option, because the leak
report code doesn't seem to be thread-safe, and thus is a bit dangerous.
Also, move the code to the very beginning to make sure leak report is
enabled before any other talloc function is used. Otherwise, these
allocations could be missed.
In commit 94782e464d, code was added to remove the first
command line argument. (Because that is essentially useless.) The code
for printing with command line on -v still assumed the first argument
should be skipped.
The only decoder which could handle demux_gif's output was vd_raw,
which has been removed recently. Instead of re-adding vd_raw, make it
work with vd_ffmpeg.
By coincidence, the FourCC "raw " fits our needs and it understood by
the ffmpeg raw decoder (apparently used in mov files going by
libavcodec/rawdec.c). Since there doesn't seem to be any good way to
transport the palette in mplayer dmuxer packets, create an AVPacket for
this purpose. (struct sh_video provides a "global" palette. Rather than
hacking vd_ffmpeg to use it, it seems cleaner to make demux_gif use
AVPacket, which supports a per-frame palette.)
Change vd_ffmpeg such that if sh_video->format is a mplayer pixel
format, and there's no other codec information, try to play it as raw
video. (The case of no codec information happens if the "generic" ffmpeg
decoder is instantiated, which is tried last. This means clashes with
actual existing formats are less likely.)
demux_mng did not initialize all fields of the bih, which made vd_ffmpeg
do invalid memory accesses when trying to copy the extradata. Also, use
IMGFMT_RGB32 instead of creating the FourCC directly. (They should be
the same, but what if mplayer changes the IMGFMT_* values.)
This also fixes demux_rawvideo.
Probably all of these are supported by libavcodec. Missing things can
be added back.
Also remove qtpalette.h. It was used by demux_mov.c, and should have
been deleted with commit 1fde09db6f.
The main excuse for removing this is that LIVE555 deprecated the API
the mplayer implementation was using. The old API still seems to be
somewhat supported, but must be explicitly enabled at LIVE555
compilation, so mplayer won't always work on any user installation.
The implementation was also very messy, in C++, and FFmpeg support is
available as alternative.
Remove it completely.
libavformat replaces demux_audio completely. I don't know/care what
vivo (demux_viv) is. libavformat has a Real demuxer; it seems it works
slightly better, with a different set of bugs.
Support for internal libdvdread has been removed in commit 41fbcee1f5,
but some bits have been missed in Makefile/configure.
Support for libdvdread as normal library is left unchanged.
With a HiDPI screen, for performance and backwards compatibility
reasons, AppKit requests an OpenGL surface with a pixel number that
equals the user points number. After the image is rendered to this
smaller surface, it is upscaled so that its dimensions are comparable
across screens of different DPIs. The applied scaling is not that good
and makes the video/subtitles blurry; this is not acceptable for a
video player.
Request AppKit to use a high resolution OpenGL surface to back the
mplayer2 OpenGL view. Also set the window pixel size information
correctly in the VO object by converting user points to actual pixels.
All the system version checks are done at runtime so that the feature
is available on OSX 10.7 even with a binary compiled with older SDKs.
Also replace is_lion_or_better() with is_osx_version_at_least(10, 7, 0)
which is defined in osx_common.
When files are double clicked or drag and dropped to the mplayer2 icon they
can be in random order. This commit forces alphabetical order.
Opening them with command + down arrow already worked correctly.
Remove functions that aren't called anymore:
* `osx_foreground_hack` was replaced by the NSApplication's
activateIgnoringOtherApps: in cocoa_common.
* Aspect ratio functions were not called by the "new" cocoa backend,
since the corresponding menu item was deleted.
As of OS X 10.8 Apple completely removed X11 from the system.
gl_common.h was including gl.h using the path <GL/gl.h>. This path
comes from the X11 headers, which are missing in 10.8.
Change gl_common.h to include gl.h from Apple's OpenGL implementation
as <OpenGL/gl.h> if X11/XQuartz is not detected.
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.
When the internal mplayer MPEG demuxer was removed (commit 1fde09db),
the default demuxer when using dvdnav was set to libavformat. Now it
turns out that this doesn't work with libavformat. It will terminate
playback right after the audio runs out (instead of looping it like the
video, or whatever it's supposed to do). I'm not sure what exactly the
problem is, but since 1. even mplayer-svn can't handle DVD menus
directly (missing highlights), 2. DVD menus are essentially worthless,
and 3. I don't directly watch DVDs, don't bother with it and remove it.
For basic playback, there's still libdvdread support.
Also, use pkg-config for libdvdread, and drop support for in-tree
libdvdread. Remove support for in-tree libdvdcss as well.
Remove the win32 loader - the win32 emulation layer, as well as the
code for using DirectShow/DMO/VFW codecs. Remove loading of xanim,
QuickTime, and RealMedia codecs.
The win32 emulation layer is based on a very old version of wine.
Apparently, wine code was copied and hacked until it was somehow able
to load a limited collection of binary codecs. It poked around in the
code segment of some known binary codecs to disable unsupported win32
API calls to make them work. Example from module.c:
for (i=0;i<5;i++) RVA(0x19e842)[i]=0x90; // make_new_region ?
for (i=0;i<28;i++) RVA(0x19e86d)[i]=0x90; // call__call_CreateCompatibleDC ?
for (i=0;i<5;i++) RVA(0x19e898)[i]=0x90; // jmp_to_call_loadbitmap ?
for (i=0;i<9;i++) RVA(0x19e8ac)[i]=0x90; // call__calls_OLE_shit ?
for (i=0;i<106;i++) RVA(0x261b10)[i]=0x90; // disable threads
Just to show how utterly insane this code is. You wouldn't want even
your worst enemy to have to maintain this. In fact, it seems nobody
made major changes to this code ever since it was committed.
Most formats can be decoded by libavcodecs these days, and the loader
couldn't be used on 64 bit platforms anyway. The same is (probably)
true for the other binary codecs.
General note about how support for win32 codecs could be added back:
It's not possible to replace the win32 loader code by using wine as
library, because modern wine can not be linked with native Linux
programs for certain reasons. It would be possible to to move DirectShow
video decoding into a separate process linked with wine, like the
CoreAVC-for-Linux patches do. There is also the mplayer-ww fork, which
uses the dshownative library to use DirectShow codecs on Windows.
Libavformat does not distinguish between "no codec_tag given" and
"codec_tag given, value is 0". 0 can be a valid value. Change
demux_lavf to assume that 0 always means unset for audio. This
prevents incorrect selection of the PCM decoder, which includes
"format 0x0" in its codecs.conf entry. The video case accepts 0 iff
codec_id is RAWVIDEO, but there's no obvious similar check possible
for audio. Thus this could possibly cause issues if a file really uses
0 to mean uncompressed audio.
The libavcodec Musepack SV8 decoder returned 2 bytes consumed for 1
byte input, which triggered a crash due to negative input packet size
later. Add a sanity check to prevent crashes with this type of minor
decoder overreads. Also add a check to parser consumed data.
stream_file always printed "File not found" if it could not open a
file, even though this could be due to other reasons such as
permission problems. Print strerror() information instead. This
changes the output for "mplayer /etc/shadow" from
File not found: '/etc/shadow'
to
Cannot open file '/etc/shadow': Permission denied
Change "run" command to expand properties.
Patch by Jan Christoph Uhde [Jan UhdeJc com], documentation
part changed by me.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35081 b3059339-0415-0410-9bf9-f77b7e298cf2
Author: reimar
This happened on system without a vdpau driver installed. It's
especially bad because vdpau is the default VO.
I'm not sure when this bug was introduced, and it seems to exist in
upstream mplayer2 too.
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.
The terminal status line (showing playback status etc.) was too long
for the standard 80 column width in some cases. Shorten the output by
abbreviating some fields with single letters.
Change "(PAUSED!)" to "(Paused)". This looks nicer.
Move the speed field forward and omit the explicit "header". It's
probably intuitively clear that "x2.00" means double speed.
The field showing the playback time in seconds was padded with spaces.
This just takes space away and wasn't really needed.
This was a hack for .mov reference files. The mov demuxer, which
triggered this code, has been removed in commit 1fde09db6f.
The code serves no purpose anymore, and it was bogus in the first
place. (This mov feature should have been handled either by the core's
timeline support, or as normal playlist.)
The assumption is that JPG screenshots are more useful in general.
Lossless screenshots made from lossy videos are just a waste of space.
Increase JPEG quality a bit. There's a tradeoff between quality and
size, and since JPEG is the default now, attempt to balance the
JPEG settings to provide sane defaults for general use cases.
It's not clear why this video filter supported OSD rendering.
The manpage says:
"Can be used for placing subtitles/OSD in the resulting black bands."
But every single VO already does this if vf_expand adds black borders.
This feature is 100% pointless.
Rename -slave to -slave-broken to prevent slave mode applications from
working. Do this to prevent horrible user experiences, in case someone
should attempt to try this version of mplayer with smplayer and others.
This also makes it clear that we don't intend to keep slave mode
compatibility, because the slave mode protocol is horrible and bad.
See the changes in options.rst for further reasons and comments.
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.
Commit 9c02ae7e95 set the sh variable (see diff) to the struct of
type sh_sub instead the one of sh_stream. Unfortunately this didn't
crash, and merely made the OSD show "unknown" for the language.
Commit 804bf91570 accidentally removed the display of the track
title. Add it back.
The documentation is mostly taken from the help text embedded in the
code of each output driver.
vo_v4l2 and ao_v4l2 have been removed.
Minor modifications to vo_xv, vo_directx and vo_gl.
