This is a minor simplification. The original intend was to only open a
file if opening the image encoder went well, but this obscure special
case is not worth bothering the image writer functions with more error
handling.
This adds the --screenshot-template option, which specifies a template
for the filename used for a screenshot. The '%' character is parsed as
format specifier. These format specifiers insert metadata into the
filename. For example, '%f' is replaced with the filename of the
currently played file.
The following format specifiers are available:
%n Insert sequence number (padded with 4 zeros), e.g. "0002".
%0Nn Like %n, but pad to N zeros (N = 0 to 9).
%n behaves like %04n.
%#n Like %n, but reset the sequence counter on every screenshot.
(Useful if other parts in the template make the resulting
filename already mostly unique.)
%#0Nn Use %0Nn and %#n at the same time.
%f Insert filename of the currently played video.
%F Like %f, but with stripped file extension ("." and rest).
%p Insert current playback time, in HH:MM:SS format.
%P Like %p, but adds milliseconds: HH:MM:SS.mmmm
%tX Insert the current local date/time, using the date format X.
X is a single letter and is passed to strftime() as "%X".
E.g. "%td" inserts the number of the current day.
%{prop} Insert the value of the slave property 'prop'.
E.g. %{filename} is the same as %f. If the property doesn't
exist or is not available, nothing is inserted, unless a
fallback is specified as in %{prop:fallback text}.
%% Insert the character '%'.
The strings inserted by format specifiers will be checked for
characters not allowed in filenames (including '/' and '\'), and
replaced with the placeholder '_'. (This doesn't happen for text that
was passed with the --screenshot-template option, and allows specifying
a screenshot target directory by prefixing the template with a relative
or absolute path.)
If the screenshot_force video filter is inserted, taking screenshots will
always use the video filter, and skip the VO specific screenshot code.
This can be useful if the VO code causes problems, or if it's intended to
take screenshots from a specific location in the filter chain.
The 'screenshot' filter is intended as fallback, it's not used if possible.
Callign add_step_frame is not necessary, because mplayer always decodes
at least one frame when starting a new file. Calling pause_player is
sufficient, and unlike add_step_frame doesn't play any audio.
The cue code will open the .bin file with demux_rawaudio if the file
can't be opened otherwise. In case the .bin file isn't in the exact
format demux_rawaudio uses (usually 44100 Hz, 2 ch, s16le PCM), noise
will be played.
This is done only if no other demuxer could open the file, and the
file extension is ".bin".
Ensure that chapters are sorted by time. There are some broken mkv
files that have chapters in random order. Using simple chapter
skipping with the seek_chapter slave command is very confusing and
just doesn't work if the chapters are not in order.
The chapters are resorted every time a chapter is added, that would
make the chapter list unsorted. While this is algorithmically very
stupid, it doesn't require changes per demuxer, or reasoning when
exactly chapters could be added. Turning this into an insertion sort
isn't worth the code, and the added demuxer_sort_chapters() function
could possibly be moved to the "right" place later.
This is not done when ordered chapters are used, because timeline
support uses different data structures for chapters.
Install a signal handler on SIGCONT, and restore the terminal
attributes with tcsetattr() if it happens. This is needed with some
shells (such as tcsh) that don't restore the terminal attributes set
by mplayer. Without this, terminal I/O doesn't work as intended after
resume with these shells.
Fixes#155.
If mplayer is started with -msglevel cplayer=-1, there can't be any
terminal OSD output, but the terminal line was still cleared
unconditionally. Fix this by using mp_msg(), which will throw away the
output to clear the terminal if disabled.
Fixes#154.
This was caused by a demuxer trying to undo the header read when probing
for its file format. This is pointless in any case, because the core
demuxer code seeks back to the start of the file when initializing a
demuxer.
The commit "input: handle UTF-8 terminal input" accidentally messed up
the handling of certain special keys. Apparently only KEY_ENTER was
affected by this, because the code was valid UTF-8, but didn't directly
map to the keycode.
This deletes all playlist elements, except the currently active
playlist entry.
NOTE: this doesn't remove parent nodes in the case when we really have
a play tree (as opposed to a play list). Apparently this doesn't cause
any harm.
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.)
Fix spelling.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34006 b3059339-0415-0410-9bf9-f77b7e298cf2
Fix disabled code.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34007 b3059339-0415-0410-9bf9-f77b7e298cf2
Remove pointless pointer indirection for shader program strings.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34016 b3059339-0415-0410-9bf9-f77b7e298cf2
Remove usage of glColor3f, there is not really a point in it.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34149 b3059339-0415-0410-9bf9-f77b7e298cf2
The --paused option will start the player in paused state. That means it
will start out with a still image of the first frame.
This can be useful in combination with --ss to inspect a certain frame.
Caveat: this plays a small bit of audio at the start, which might be
perceived as an annoying artifact. This is because this is implemented
by frame stepping after initialization in order to decode and display
the first video frame.
Using type = -1 for terminating the command argument list was an
unnecessary complication. Change it to 0 to make use of default
initialization. Remove the explicit termination from the command
definitions. Now the argument list is automatically terminated by C
default initialization rules.
Also remove other redundant {0} initializers.
When an argument's default value is actually initialized to something other
than 0, make the field being initialized explicit (e.g. {1} becomes
{.i = 1}).
Try to make use of whitespace more consistent.
Setting the WM_NAME/WM_ICON_NAME window properties didn't always work:
apparently there are some characters that can't be represented in the X
STRING or COMPOUND_TEXT encodings, such as U+2013 EN DASH. The function
Xutf8TextListToTextProperty partially converts the string, and returns
a value different from 'Success'. This means vo_x11_set_property_string
didn't set these window properties.
On most modern window managers, this is not a problem, since these use
the _NET_WM_NAME/_NET_ICON_NAME and the UTF8_STRING encoding. Some older
WMs like IceWM don't read these, and the window title remains blank.
It's not clear what exactly we should do in this situation, but fix it
by setting set the WM_NAME/WM_ICON_NAME properties as UTF8_TEXT. This
violates the ICCCM, but at least IceWM seems to handle this well.
See also:
http://lists.freedesktop.org/archives/xorg/2004-September/003391.htmlhttp://lists.freedesktop.org/archives/xorg/2004-September/003395.html
Also fix a minor memory leak when conversion to COMPOUND_TEXT fails.
The default compression setting is 7, which is hopefully a good balance
between speed of compression, and resulting file sizes. The maximum png
compression will be very slow even on fast computers. On the other hand,
the lowest compression setting produces files of several MB size with
normal video resolutions, which should be avoided as well.
The screenshot image file type can now be selected with the
--screenshot-filetype option. The --screenshot-jpeg-quality option
controls the compression setting of the written JPEG image file.
Now the option --term-osd=force will cause mplayer to display all OSD
messages on the terminal, even if there is video.
Possible values for --term-osd:
- auto: use video OSD, or of there's no video, the terminal (default)
- off: always use video for OSD
- force: always use terminal for OSD
-term-osd and --term-osd are equivalent to --term-osd=force. This
changes the meaning of the option, since -term-osd used to enable the
OSD default behavior, i.e. --term-osd=auto.
-noterm-osd has the same effect as --term-osd=off, and is kept for
compatibility.
Implementation note:
The location for the OSD text was shared between the two code paths (it
was in osd_state.osd_text). We can't rely on the fact that the video-OSD
update code normally isn't run when --term-osd is called. When e.g.
panscan is updated, the video OSD code will draw the OSD anyway. This
would sometimes show unwanted OSD text on the video.
Deal with this by putting the current terminal-OSD text in a different
place (in MPContext.terminal_osd_text) to deal with this.
If an m_option_type_choice option is declared with M_OPT_IMPLICIT_DEFAULT
in its flags, it doesn't require a parameter. For example, if --opt is
such an option, it can be invoked as "--opt=val", "-opt", or "--opt".
The last two will set the option to the first choice the option declares.
Note that "-opt val" (using the old option syntax) is not allowed in this
case, as it would be ambiguous.
Normal option parsing should be unaffected.
Playing a .cue file directly will now parse the .cue file, and load and
play the file(s) referenced in the cue. If multiple files are referenced,
a timeline including all files will be created to create the impression
of a single, flat audio file containing all the tracks.
For each track, a chapter is created. The chapter navigation commands can
be used to jump between tracks. The chapter titles will use the string
provided by the track's TITLE cue command. (The -identify command can be
used to print all chapters in a not so user friendly way.)
Other than the chapter names, there is no attempt at displaying or exposing
any other meta data contained in the cue files yet.
The handling (or lack of thereof) of gaps (track pregaps and postgaps) is
probably not correct yet. In general, mplayer's mapping of tracks to the
source audio files can be verified by examining the timeline, which will
be printed when passing the -v switch.
Note that this has nothing to do with the old cue:// support. The old code
isn't touched, and is still only able to play .cue/.bin pairs. Prefixing a
.cue file with cue:// will always invoke the old code, while playing a .cue
file directly (i.e. "mplayer file.cue") will always use the new code.
Playing audio images (.cue/.bin pairs of files) doesn't work yet.
bstr_strip_ext and bstr_get_ext were taken from find_subfiles.c.
bstr_cut is extended to work like bstr_splice: passing a negative
argument will start counting from the end of the string, e.g.
bstr_cut("abc", -2) == "bc"
If digital pass-through is used, this supported setting the volume (just
mute, actually), but not getting the volume. This will probably lead to a
stuck mute state in the mplayer frontend. Make the code respond to volume
queries even if digital pass-through is used.
Ideally, ao_coreaudio should implement full mute control, but I can't
even test on OSX.
The mixer frontend code can now make use of a proper system mixer mute
toggle, if the audio output driver supports it.
The consequence is that, if support is available, mplayer will no longer
temporarily set the system volume to 0 if mute is enabled.
Generally, the code now deals with the following combinations of available
AO features:
- software volume control forced by user (--softvol / soft_vol flag)
=> if enabled, never touch the "hardware" controls
- "hardware"/driver volume control available (whether
AOCONTROL_GET/SET_VOLUME works)
=> if not available, enable volume controls by enabling softvol
- "hardware"/driver mute control (AOCONTROL_GET/SET_MUTE)
=> if not available, emulate by setting volume to 0
- whether the volume+mute controls are kept or not when the AO is closed
(indicated by ao->no_persistent_volume)
=> if not persistent, restore the volume/mute next time the AO is opened
The mplayer frontend (specifically, mixer.c) needs to know this. If the
audio output doesn't remember the volume across reinitialization, the
frontend will restore the volume settings. There is also the assumption
that the volume setting isn't global in this case (i.e. changing it
won't change the volume of other applications or annoy the user
otherwise).
None of these changes have been tested. I'm guessing that ESD and NAS do
per-connection non-persistent volume settings.
Changing the volume when softvol is enabled or if the audio output driver
doesn't support volume controls causes insertion of the "volume" filter.
This fails with AC3. Since the filter wasn't removed after that, and the
filter chain was in a bogus state, random crashes occured past this
point.
Fix it by reinitializing the filter chain completely on failure. Volume
controls simply won't work. (This can't be fixed, because AC3 is a
compressed format, and would require additional decoding/encoding passes
in order to support arbitrary volume changes.)
This also affects balance controls.
I'm not sure what's the point of this feature. Aside from that, the EDL
code is relatively buggy anyway, and I see no reason why such an obscure
feature should be left in, if it possibly causes bugs.
Before this commit, the mute state was only reset when either mute was
explicitly cleared, or the volume was changed via mplayer controls. If
the volume controls are connected to the system mixer, and the system
mixer volume is changed otherwise (e.g. with alsamixer), the mute
setting was inconsistent.
Avoid this by checking the volume. If the returned volume is not 0, the
mute flag is considered invalid. This relies on system mixers always
returning a volume of 0 when mplayer has set the volume 0.
Possible caveat: if the audio output's volume control don't return a
volume of exactly 0 after 0 was written, enabling mute basically won't
work. It will set the volume to silence, forget the previous volume, and
report that mute is disabled.
Muting audio is implemented by setting the volume controls to 0. This
has the annoying consequence that attempting to change the volume while
the audio is muted will reset the user's volume setting. E.g. increasing
the volume while muted will start from 0, instead from the volume that
was set before muting. Changing the volume while muted effectively resets
the volume to 0 (which is not very useful), with no possibility of
restoring the old voume.
This commit makes mplayer always report the volume that was set when mute
was enabled while mute is still active.
Caveat: this might be have confusing effects when the volume control is
directly connected with a system wide mixer setting. Now it's even less
obvious (and thus more confusing) that muting will set the mixer volume
to 0.
Also always clip input volumes, and remove some minor code duplication.
When you mute audio, mplayer is supposed to restore the volume controls
on exit. This affects when --softvol isn't used and the audio output
driver volume controls directly affect the system wide volume controls.
This wasn't done in some cases.
Some audio outputs don't provide access to a system-wide mixer control, and
do per-application audio mixing. Further, some of these forget the volume
as soon as the audio device is closed. This can be annoying, because
mplayer will "forget" the volume when playing a new file or when crossing
ordered chapter boundaries. Support restoring the volume on audio
reinitialization if an audio output driver knowingly behaves this way.
(This doesn't change that mplayer never writes any settings into the config
file, including volume settings.)
This commit doesn't yet change any actual output driver to use this code.
Hopefully make some logic in the volume restore code a bit more robust.
wm4
reimar
Uoti Urpala