| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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"
|
| |\ |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This patch adds a "size" parameter, which scales the filter radius
according to movie diagonal, the unit being percent of diagonal.
This makes the effect far more predictable across movies of different
resolutions.
Usage example (with possibly useless values):
-vf gradfun=strength=1.2:size=2.3
Based on a patch by Radosław Szkodziński <astralstorm@gmail.com>
|
| | | |
|
| |\ \ |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This is an experiment.
The change probably doesn't matter much.
One issue with the old code was that "large" images caused each sub-image
to be created and rendered as a new texture. "Large" in this case means
larger than 32x32 pixels, which actually isn't very large with screen
sizes beyond 1500x1000 pixels. This means rendering a simple subtitle for
a fullscreened video may allocate many small textures, one for each glyph.
On the other hand, the old code could be fixed by tuning the texture sizes
for "modern" work loads.
Also, the new code uses less deprecated OpenGL features and draws all
sub-images in one batch.
There are two possible issues the new code could cause:
- Drivers could have performance issues with the larger texture sizes and
the number of glTexSubImage2D calls on it
- There is only one EOSD texture, which could become full (it's enlarged
on demand, but restricted by driver texture size limitations)
It has been reported that this is faster on OSX with ATI GPUs than the old
code.
|
| | |/
| |
| |
| |
| |
| |
| | |
The code in eosd_packer.c/.h is taken from vo_vdpau.c and has been made
independent from vdpau API specifics. This allows other VOs, which need
to pack the small EOSD images into a large surface for efficiency, to use
this code.
|
| |\ \ |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
Do this, because the "Master" channel normally provides proper mute
control.
The old default can be forced with: --mixer-channel=PCM
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| | | |
| | |
| | |
| | |
| | | |
This will make the mplayer frontend restore the volume on its own when
the audio device is reinitialized.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
At least in the case when switching to no audio track and then switching
back, the volume settings were not restored with --softvol. Fix this by
moving the call restoring the settings to a better place.
|
| | | | |
|
| | | |
| | |
| | |
| | | |
The string format used in print_fmt() is taken from init_audio_filters().
|
| | | |
| | |
| | |
| | |
| | |
| | | |
Similarly to the last commit, restore the balance setting when switching
to a new file. Unlike the volume setting, balance is always implemented
as filter, so this affects usage without --softvol too.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When --softvol is enabled, the volume set by the "volume" property is
reset when changing to a new file or crossing ordered chapter boundaries.
Fix this by explicitly restoring the volume on audio reinitialization.
Now the behavior with --softvol should be the same as if a system mixer
is used, and the volume should be persistent across file changes.
This also works around an inconsistency with the mute flag. The frontend
assumed the mute flag is persistent across file changes, which was not
true with --softvol.
If not resetting the volume on playing new files is undesired, it can
be avoided by putting volume=100 in the mplayer config file.
|
| | |/
| |
| |
| |
| |
| | |
There should be no real semantic changes.
Remove the mixer_setbothvolume macro, as it was unused.
|
| |\ \ |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
There were some slight differences between what input.conf mapped, and
what was in input.c def_cmd_binds[]. Make them match.
Add some minor documentation improvements in input.cfg.
Also remove double comments ('##'), because they were confusing.
|
| | | |
| | |
| | |
| | |
| | | |
Use the <X11/keysymdef.h> xlib header instead. I'm not sure why mplayer
defined these constants itself.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
At least on some keyboards, the key between '0' and 'Enter' on the
key pad is mapped to KP_Separator. Since X11 VOs accept unicode
input, the mplayer keycode this key generates depended on the numlock
state, and with numlock enabled this mapped to an ASCII character.
This is probably not what the user wanted, since two physical keys
will always map to the same key code.
Map it to KP_DEC.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This assumes the terminal uses UTF-8. If invalid UTF-8 is encountered (for
example because the terminal uses a legacy encoding), the code falls back
to the old method and feeds each byte as key code to the input code.
In theory, UTF-8 input could randomly fail, because the code in getch2.c
doesn't try to fill the input buffer correctly with input sequences
longer than a byte. This is a problem with the design of the existing
code.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This change allows using non-ASCII keys with X11. These keys were ingored
before.
Technically, this creates an invisible, non-interactive input method
context. If creation fails, the code falls back to the old method, which
allows a subset of ASCII only.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This moves all key codes above the highest valid unicode code point (which
is 0x10FFFF). All key codes below MP_KEY_BASE now directly map to unicode.
Configuration files (input.conf) can contain unicode characters in UTF-8
to map non-ASCII characters/keys.
This shouldn't change anything user visible, except that "direct key codes"
(as used in input.conf) will change their meaning.
|
| | |/
| |
| |
| | |
Parts taken from libavutil's GET_UTF8 and slightly modified.
|
| |\ \ |
|
