This readds a more or less completely new dvdnav implementation, though
it's based on the code from before commit 41fbcee. Note that this is
rather basic, and might be broken or not quite usable in many cases.
Most importantly, navigation highlights are not correctly implemented.
This would require changes in the FFmpeg dvdsub decoder (to apply a
different internal CLUT), so supporting it is not really possible right
now. And in fact, I don't think I ever want to support it, because it's
a very small gain for a lot of work. Instead, mpv will display fake
highlights, which are an approximate bounding box around the real
highlights.
Some things like mouse input or switching audio/subtitles stream using
the dvdnav VM are not supported.
Might be quite fragile on transitions: if dvdnav initiates a transition,
and doesn't give us enough mpeg data to initialize video playback, the
player will just quit.
This is added only because some users seem to want it. I don't intend to
make mpv a good DVD player, so the very basic minimum will have to do.
How about you just convert your DVD to proper video files?
The mpv.desktop file is taken from the Arch package [1]. It appears to
be based on the mplayer2 git mplayer.desktop file (e.g. very similar
MimeType field), with minor modifications applied by Arch package
maintainers.
Note that for now, this doesn't show a terminal (Terminal=false), which
might not always be ideal. For example, if the file is audio only, or
if VO initialization fails for some reason, mpv will run in the
background and play audio without showing a window. But users prefer
running it without terminal, and don't want to play audio files with
it.
Maybe a --force-window option will be added in the future, which would
always create a VO window, and compensate for these issues.
[1] https://aur.archlinux.org/packages/mpv-git/
Remove options which are too obscure and most likely not very useful in
general, or update them to something more modern. Add some comments
about how configuration files work in general.
This affects MOUSE_MOVE and MOUSE_LEAVE. Both are needed internally
(such as for the OSC), but not really useful for input.conf. Since the
warning has the purpose of notifying the user that a key is unmapped and
what key name to use for setting up a binding in input.conf, the warning
is rather useless in this case. It's also annoying in combination with
the
--no-input-default-bindings option, since that removes the default
bindings to "ignore" for these keys.
The png file added to etc/ are taken from the link mentioned in commit
303096b, except that they have been converted to 16 bit, sRGB (with
color profile info dropped, if there was one), and transparent pixels
reset for better compression.
The file x11_icon.bin is generated by gen-x11-icon.sh. I'm adding it to
the git repo directly, because the script requires ImageMagick, and we
don't want to make building even more complicated.
The way how this is done is basically a compromise between effort
required in x11_common.c and in gen-x11-icon.sh. Ideally, x11_icon.bin
would be directly in the format as required by _NET_WM_ICON, but trying
to write the binary width/height values from shell would probably be a
nightmare, so here we go.
The zlib code in x11_common.c is lifted from demux_mkv.c, with some
modifications (like accepting a gzip header, because I don't know how to
make gzip write raw compressed data).
I suspect most users will just copy etc/input.conf when they want to
remap some default bindings. But usually this means the user even copies
bindings he doesn't care about, and it's better if the user maps only
the bindings in his input.conf the user intends to remap.
Comment all bindings in etc/input.conf. Since this file also defines the
builtin defaults and is baked into the mpv binary, we have to do
something to get them anyway, even though they are commented. Do this by
having input.c "uncomment" the bindings in the baked in input.conf. (Of
course this is done only for the builtin config, not configs loaded from
disk.)
I would like to thank Chris Ward (@tenzerothree, http://tenzerothree.com/) for
working on the art for these icons and bringing some eye candy to the project.
The PSDs made by Chris are available on our Dropbox [1], along with the exports
I made to create OSX and Windows icons. The PSDs are almost completly vector
and all the resolutions look really similar, except the 16px favicon which was
handcrafted to look better and more recognizeable on the smaller pixel budget.
For Mac OS X the icons were created using iconutils on the PNGs iconsets
exported from the PSDs. These even support retina resolutions (except 512@2x).
For Windows the .ico file was created with imagemagick. The included images
are 16px, 24px, 32px, 48px 64px, 256px. These are the resolutions listed on
MSDN for supporting Windows XP [2] and Windows versions based on Aero [3].
Only 32bit PNGs were used since it is 2013.
For Linux nothing changed yet, even though @wm4 talked about using the PNGs
directly there. This will probably be dealt with in a later commit.
[1]: https://www.dropbox.com/sh/yelfoj9tbft7o06/A8vOT6JKaG
[2]: http://msdn.microsoft.com/en-us/library/ms997636.aspx
[3]: http://msdn.microsoft.com/en-us/library/aa511280.aspx
Change how the HW decoding stuff is organized, the way it's initialized
in particular. Instead of duplicating the list of supported codecs for
hwaccel decoders, add a probe function which allows each decoder to
report whether it supports a given codec.
Add an "auto" choice to the --hwdec option, which automatically enables
hardware decoding if libavcodec and/or the VO supports it.
What mpv prints on the terminal changes a bit. Now it will just print
a single line whether hw decoding is used or not (and nothing at all if
no hw decoding at all was requested). The pretty violent fallback from
hw decoding to software decoding is still quite verbose and evil-looking
though.
Support horizontal and vertical axes of input devices.
If the input device support precise scrolling with an input value then it
should first be scaled to a standard multiplier, where 1.0 is the default.
The multiplier will then applied to the following commands if possible:
* MP_CMD_SEEK
* MP_CMD_SPEED_MULT
* MP_CMD_ADD
All other commands will triggered on every axis event, without change the
values specified in the config file.
This slightly increases file size due to needless downscaling on the device due
to aspect correction, but keeps quality as is and prevents encoding errors
caused by odd height/width.
Also, implement mouse leave events for X11. But evne on other
platforms, these events will be generated if mouse crosses a section's
mouse area boundaries within the mpv window.
Before this commit, mouse movement events emitted a special command
("set_mouse_pos"), which was specially handled in command.c. This was
once special-cased to the dvdnav and menu code, and did nothing after
libmenu and dvdnav were removed.
Change it so that mouse movement triggers a pseudo-key ("MOUSE_MOVE"),
which then can be bound to an arbitrary command. The mouse position is
now managed in input.c. A command which actually needs the mouse
position can use either mp_input_get_mouse_pos() or mp_get_osd_mouse_pos()
to query it. The former returns raw window-space coordinates, while the
latter returns coordinates transformed to OSD- space. (Both are the same
for most VOs, except vo_xv and vo_x11, which can't render OSD in
window-space. These require extra code for mapping mouse position.)
As of this commit, there is still nothing that uses mouse movement, so
MOUSE_MOVE is mapped to "ignore" to silence warnings when moving the
mouse (much like MOUSE_BTN0).
Extend the concept of input sections. Allow multiple sections to be
active at once, and organize them as stack. Bindings from the top of
the stack are preferred to lower ones.
Each section has a mouse input section associated, inside which mouse
events are associated with the bindings. If the mouse pointer is
outside of a section's mouse area, mouse events will be dispatched to
an input section lower on the stack of active sections. This is intended
for scripting, which is to be added later. Two scripts could occupy
different areas of the screen without conflicting with each other. (If
it turns out that this mechanism is useless, we'll just remove it
again.)
This adds support for libquvi 0.9.x, and these features:
- start time (part of youtube URL)
- youtube subtitles
- alternative source switching ('l' and 'L' keys)
- youtube playlists
Note that libquvi 0.9 is still in development. Although this seems to
be API stable now, it looks like there will be a 1.0 release, which is
supposed to be the next stable release and the actual successor of
libquvi 0.4.x.
This commit addresses some issues with the users had with the previous
implementation in commit c39efb9. Here's the changes:
* Use Quartz Event Taps to remove Media Key events mpv handles from
the global OS X queue. This prevents conflicts with iTunes. I did this on
the main thread since it is mostly idling. It's the playloop thread that
actually does all the work so there is no danger of blocking the event tap
callback.
* Introduce `--no-media-keys` switch so that users can disable all of mpv's
media key handling at runtime (some prefer iTunes for example).
* Use mpv's bindings so that users can customize what the media keys do via
input.conf. Current bindings are:
MK_PLAY cycle pause
MK_PREV playlist_prev
MK_NEXT playlist_next
An additional benefit of this implementation is that it is completly handled
by the `macosx_events` file instead of `macosx_application` making the
project organization more straightforward.
After killing the non functional AR support in c8fd9e5 I got much complaints so
this adds AR support back in (and it works). I am using the HIDRemote class by
Felix Schwarz and that part of the code is under the BSD license. I slightly
modified it replacing [NSApplication sharedApplication] with NSApp. The code
of the class is quite complex (probably because it had to deal with all the
edge cases with IOKit) but it works nicely as a black box.
In a later commit I'll remove the deprecation warnings caused by HIDRemote's
usage of Gestalt.
Check out `etc/input.conf` for the default bindings.
Apple Remote functionality is automatically compiled in when cocoa is enabled.
It can be disabled at runtime with the `--no-ar` option.
A "watch later" command is now mapped to Shift+Q. This quits the player
and stores the playback state in a config file in ~/.mpv/watch_later/.
When calling the player with the same file again, playback is resumed
at that time position.
It's also possible to make mpv save playback state always on quit with
the --save-position-on-quit option. Likewise, resuming can be disabled
with the --no-resume-playback option.
This also attempts to save some playback parameters, like fullscreen
state or track selection. This will unconditionally override config
settings and command line options (which is probably not what you would
expect, but in general nobody will really care about this). Some things
are not backed up, because that would cause various problems. Additional
subtitle files, video filters, etc. are not stored because that would be
too hard and fragile. Volume/mute state are not stored because it would
mess up if the system mixer is used, or if the system mixer was
readjusted in the meantime.
Basically, the tradeoff between perfect state restoration and
complexity/fragility makes it not worth to attempt to implement
it perfectly, even if the result is a little bit inconsistent.
Allows stepping back one frame via the frame_back_step inout command,
bound to "," by default.
This uses the precise seeking facility, and a perfect frame index built
on the fly. The index is built during playback and precise seeking, and
contains (as of this commit) the last 100 displayed or skipped frames.
This index is used to find the PTS of the previous frame, which is then
used as target for a precise seek. If no PTS is found, the core attempts
to do a seek before the current frame, and skip decoded frames until the
current frame is reached; this will create a sufficient index and the
normal backstep algorithm can be applied.
This can be rather slow. The worst case for backstepping is about the
same as the worst case for precise seeking if the previous frame can be
deduced from the index. If not, the worst case will be twice as slow.
There's also some minor danger that the index is incorrect in case
framedropping is involved. For framedropping due to --framedrop, this
problem is ignored (use of --framedrop is discouraged anyway). For
framedropping during precise seeking (done to make it faster), we try
to not add frames to the index that are produced when this can happen.
I'm not sure how well that works (or if the logic is sane), and it's
sure to break with some video filters. In the worst case, backstepping
might silently skip frames if you backstep after a user-initiated
precise seek. (Precise seeks to do indexing are not affected.)
Likewise, video filters that somehow change timing of frames and do not
do this in a deterministic way (i.e. if you seek to a position, frames
with different timings are produced than when the position is reached
during normal playback) will make backstepping silently jump to the
wrong frame. Enabling/disabling filters during playback (like for
example deinterlacing) will have similar bad effects.
In some cases (when using tune=animation as an additional option), the
N900 profile caused use of 6 reference frames, where Level 3.0 only
allows 5 reference frames. This prevented playback on the Nokia N900.
This has been fixed by always specifying refs=5.
This yields generally smaller files, by avoiding upscaling at all times.
This method may or may not be useful for iOS, needs testing there.
Note: this uses three instances of vf_scale:
1. Scale to target dimensions, ONLY if both are <= original video
dimensions.
2. Failing that, scale to width*<calculated height by display aspect>,
ONLY if <calculated height by display aspect> <= original video
height.
3. Failing that, scale to <calculated width by display aspect>*height.
When the test before failed, we KNOW that <calculated width by
display aspect> <= original video width.
So basically, only one of the three scalers should ever be active, as
the last two scalers only can ever have an effect if the aspect ratio
mismatches the video.
As for danger of roundoff errors:
If scaler 1 succeeded, we have won. Scalers 2 and 3 will never do
anything, because display resolution == video resolution. Here it is
crucial that no rounding of video size to display size takes place; in
other words, the target display size already MUST be even, which it is
because we pass 2 to the rounding parameter of the dsize filter.
Scaler 2 and 3 are obviously mutually exclusive, as they depend on
opposite aspect ratio conditions.
We later should put this functionality directly into vf_scale...
I doubt anyone needs to adjust hue on a frequent basis, and gamma is
much more useful.
Suggestions for more radical changes of key bindings are welcome
(there's a lot of useless crap mapped).
For all suboptions, "flat" options were available by separating the
parent option and the sub option with ":", e.g. "--rawvideo:w=123". Drop
this syntax and use "-" as separator. This means even suboptions are
available as normal options now, e.g. "--rawvideo-w=123". The old syntax
doesn't work anymore.
Note that this is completely separate from actual suboptions. For
example, "-rawvideo w=123:h=123" still works. (Not that this syntax is
worth supporting, but it's needed anyway, for for other things like vf
and vo suboptions.)
As a consequence of this change, we also have to add new "no-" prefixed
options for flag suboptions, so that "--no-input-default-bindings"
works. ("--input-no-default-bindings" also works as a consequence of
allowing "-input no-default-bindings" - they are handled by the same
underlying option.)
For --input, always use the full syntax in the manpage. There exist
suboptions other than --input (like --tv, --rawvideo, etc.), but since
they might be handled differently in the future, don't touch these yet.
M_OPT_PREFIXED becomes the default, so remove it. As a minor unrelated
cleanup, get rid of M_OPT_MERGE too and use the OPT_SUBSTRUCT() macro in
some places.
Unrelated: remove the duplicated --tv:buffersize option, fix a typo in
changes.rst.
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.
This could write .edl files in MPlayer's format. Support for playing
these files has been removed from mplayer2 quite a while ago. (mplayer2
can play its own, "new" .edl format, but does not support writing it.)
Since this is a rather obscure functionality, and it's not really clear
how it should behave (e.g. what should it do if a new file is played),
and wasn't all that great to begin with (what if you made a mistake?
the "edl_mark" command sucks for editing), get rid of it.
Suggestions how to reimplement this in a nicer way are welcome. If it's
just about retrieving timecodes, this in input.conf will do:
KEY print_text "position: ${=time-pos}"
--autofit=WxH sets the window size to a maximum width and/or height,
without changing the window's aspect ratio.
--autofit-larger=WxH does the same, but only if the video size is
actually larger than the window size that would result when using
the --autofit=WxH option with the same arguments.
mplayer's video chain traditionally used FourCCs for pixel formats. For
example, it used IMGFMT_YV12 for 4:2:0 YUV, which was defined to the
string 'YV12' interpreted as unsigned int. Additionally, it used to
encode information into the numeric values of some formats. The RGB
formats had their bit depth and endian encoded into the least
significant byte. Extended planar formats (420P10 etc.) had chroma
shift, endian, and component bit depth encoded. (This has been removed
in recent commits.)
Replace the FourCC mess with a simple enum. Remove all the redundant
formats like YV12/I420/IYUV. Replace some image format names by
something more intuitive, most importantly IMGFMT_YV12 -> IMGFMT_420P.
Add img_fourcc.h, which contains the old IDs for code that actually uses
FourCCs. Change the way demuxers, that output raw video, identify the
video format: they set either MP_FOURCC_RAWVIDEO or MP_FOURCC_IMGFMT to
request the rawvideo decoder, and sh_video->imgfmt specifies the pixel
format. Like the previous hack, this is supposed to avoid the need for
a complete codecs.cfg entry per format, or other lookup tables. (Note
that the RGB raw video FourCCs mostly rely on ffmpeg's mappings for NUT
raw video, but this is still considered better than adding a raw video
decoder - even if trivial, it would be full of annoying lookup tables.)
The TV code has not been tested.
Some corrective changes regarding endian and other image format flags
creep in.
Deprecate the hardware specific video codec entries (like ffh264vdpau).
Replace them with the --hwdec switch, which requests that a specific
hardware decoding API should be used. The codecs.conf entries will be
removed at a later time, but for now they are useful for testing and
compatibility.
Instead of --vc=ffh264vdpau, --hwdec=vdpau should be used.
Add a fallback if hardware decoding fails. Most hardware decoders
(including vdpau) support only a subset of h264, and having such a
fallback is supposed to enable a better user experience.
Simplify the decoder pixel format handling by making it handle only
the case vd_lavc needs: a video stream always decodes to a single
pixel format.
Remove the handling for multiple pixel formats, and remove the
codecs.conf pixel format declarations that are left.
Remove the handling of "ambiguous" pixel formats like YV12 vs. I420 (via
VDCTRL_QUERY_FORMAT etc.). This is only a problem if the video chain
supports I420, but not YV12, which doesn't seem to be the case anywhere,
and in fact would not have any advantage.
Make the "flip" flag a global per-codec flag, rather than a pixel format
specific flag. (Some ffmpeg decoders still return a flipped image, so
this has to be done manually.) Also fix handling of the flip operation:
do not overwrite the global flip option, and make the --flip option
invert the codec flip option rather than overriding it.
ad_dvdpcm reads MPEG specific headers directly (passed through codecdata
by demux_mpg), so you couldn't use ffmpeg's "pcm_dvd" with demux_mpg.
Change demux_mpg to set the correct audio parameters directly. The code
for this is taken from ad_dvdpcm.
ad_dvdpcm is evil because it still does partial packet reads (with
demux_read_data()), and it's redundant to libavcodec anyway.
Since libavcodec doesn't have a "generic" PCM decoder, we have to go out
of out way to make it look like ad_lavc provides one: make it provide a
pseudo "pcm" decoder, which maps some format tags manually to the
individual libavcodec PCM decoders.
Format tags which uniquely map to one libavcodec could be mapped via
codecs.conf. Since defining these in tag_map[] is much shorter (one line
vs. a full codec entry in codecs.conf), and since we need tag_map[]
anyway, we don't use codecs.conf for these.
ad_pcm is evil because it still does partial packet reads (with
demux_read_data()), and it's redundant to libavcodec anyway.
The presence of inttypes.h is guaranteed by POSIX. We don't need to
check for it. We don't need to provide a compatibility header either.
Apparently libc5 systems didn't provide inttypes.h. libc5 is ancient,
unmaintained, and not used by modern Linux systems.
"screenshot" now maps to "screenshot subtitles" by default, instead of
"screenshot video". Swap the argument order: the more useful argument
should come first. Remove the compatibility aliases for numeric choices
(e.g. "screenshot 1 0" won't work anymore).
Video Decode Acceleration Framework is a framework by Apple to provide
GPU assisted H.264 decoding. It is available on Mac OS X v10.6.3 and
later with Mac models equipped with the NVIDIA GeForce 9400M, GeForce 320M,
GeForce GT 330M, ATI HD Radeon GFX, Intel HD Graphics and others.
This commit uses the new video decoder added in FFmpeg based upon this
framework.
Add a make task and python script to create a Mac OS X Application Bundle
to be used when compiling with the --enable-macosx-finder and
--enable-macosx-bundle configure flags.
The main svg icon was created by me and heavily inspired by Apple's iTunes
and AppStore icon designs. We are still looking for something better.
For the audio, movie and subtitles icons I added the main logo to MPlayer OSX
Extended icons.
Use with `make osxbundle` after running configure and make.
In input test mode, key bindings won't be executed, but are shown on the
OSD. The OSD includes various information, such as the name of the key,
the command itself, whether it's builtin, and the config file location
it was defined.
The input test mode can be enabled with "--input=test". No effort is
spent trying to react to key bindings that normally exit the player;
they are treated just like any other binding.
This changes the name of this project to mpv. Most user-visible mentions
of "MPlayer" and "mplayer" are changed to "mpv". The binary name and the
default config file location are changed as well.
The new default config file location is: ~/.mpv/
Remove etc/mplayer.desktop. Apparently this was for the MPlayer GUI,
which has been removed from mplayer2 ages ago.
We don't have a logo, and the MS Windows resource files sort-of require
one, so leave etc/mplayer.ico/.xpm as-is.
Remove the debian and rpm packaging scripts. These contained outdated
dependencies and likely were more harmful than useful. (Patches which
add working and well-tested packaging are welcome.)
Allow the values "up" and "down" as step argument for the cycle input
command. Previously, this argument was a float, which specified an
arbitrary step value and direction (similar to the add command).
Instead of "1" and "-1", "up" and "down" is to be used.
Float values are still accepted. That capability might be removed in the
future, as there's probably hardly any actual use for arbitrary step
values.
The OSD bar is very annoying when seeking. Especially when the seeks
are very small, the OSD doesn't show any interesting information. The
exact seeking commands are a use case where the user definitely never
wants to see a seek bar.
Allow using the choice type (as it used for command line) for arguments
of input commands. Change the magic integer arguments of some commands
(like seek) to use choices instead. The old numeric values are still
allowed (but only those which made sense before, not arbitrary
integers).
In order to do this, remove the input.c specific types (like
MP_CMD_ARG_INT) completely and specify commands using the m_option
types.
Also, add the special choice "-" to some arguments. It's supposed to
signify the default value, so arguments can be easily skipped. Maybe the
choice option should recognize this and not change the previous value,
but we'll leave this for later.
For now, leave compatibility integer values for all new choice
arguments, e.g. "0" maps to 0. We could let the choice option type do
this automatically, but we don't, because we want user input values and
internal mplayer values decoupled in general. The compatibility options
will be removed one day, too.
Also, remove optional args for strings - would require either annoying
additional code, or copying strings twice. It's not used, so remove it.
Previously, both the command parser and property expansion
(m_properties_expand_string) handled escapes with '\'. Move all escape
handling into the command parser, and remove it from the property code.
This removes the need to escape strings twice for commands that use
property expansion.
The command parser is practically rewritten: it uses m_option for the
actual parsing, and reduces hackish C-string handling.
Now it depends on the command whether a property wraps around, or stops
at min/max valid property value.
For practically all properties, it's quite unambiguous what the "switch"
command should have done, and there's technically no need to replace it
with these new commands. More over, most properties that cycle are
boolean anyway. But it seems more orthogonal to make the difference
explicit, rather than hardcoding it. Having different commands also
makes it more explicit to the user what these commands do, both just due
to the naming, and what wrapping policy is used. The code is simpler
too.
Replace --hardframedrop with --framedrop=hard. Rename the framedrop
property from "framedropping" to "framedrop" for the sake of making
command line options have the same name as their corresponding
property. Change the property to accept choice values instead of
numeric values.
Remove unused/forgotten auto_quality variable.
osd_show_[property_]text => show_text
osd_show_progression => show_progress
show_text, osd_show_property_text and osd_show_text both map to the
code for the previous osd_show_property_text. The only special thing
about osd_show_text is that you don't need to escape "$". Also,
unfortunately osd_show_property_text requires escaping things twice,
one time for the command parser, and the other time for the property
formatting code, while osd_show_text needed only one level of escaping.
Use "-" instead of "_" in property names. The intent is that property
names and options names should be the same (if they refer to the same
thing), and options use "-" as word separator.
Rename some other properties too, e.g. "switch_audio" -> "audio".
Add a way to translate the old property names to the new ones, similar
to the input command legacy bridge.
Update input.conf. Use the new property names, and don't use legacy
commands.
This allows to define which stream is to be used as first output stream.
This is useful because dvdauthor refuses VOB files where the audio
stream is the first stream.
This is needed by demux_mpg (and possibly by demux_ts) for PCM playback.
The decoder does the mapping from MPEG headers to the actual PCM format,
and also unpacks sample data for 20/24 bit formats.
It can't be re-implemented, because this isn't supported by libass. The
-subalign option and the associated sub-align slave property did
nothing. Remove them.
The rawaudio demuxer had a rather hard to use way to set the audio
format with the --rawaudio=format=value option. The user had to pass a
numeric value, which then was set as wFormatTag member in the
WAVEFORMATEX header.
Make it use the mplayer audio format (the same as --af=format=value).
Add a new internal pseudo audio codec tag, which is hopefully unused,
which makes ad_pcm use the value in wFormatTag as internal mplayer
audio format.
Playing non-PCM formats is disabled. (At least AC3 can be played
directly.)
This was removed in commit 6a26b4a665. Add it back, because it was
needed by demuxer_rawaudio and for PCM audio with demuxers other than
demux_lavf. (In practice, this broke rawaudio and PCM-in-Matroska only.)
Unlike with raw video, there is no single raw audio "decoder" in
libavcodec. Instead of trying to mess raw audio input into ad_ffmpeg
using a table to map audio formats to the respective libavcodec
decoders, it seems advantageous to simply add back ad_pcm.
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.
Add a new slave property which switches the current Matroska edition.
Since each edition can define an entirely new timeline, switching the
edition will simply restart playback at the beginning of the file with
the new edition selected.
Add 'E' as new keybinding to step the edition property.
DVD titles are still separate. Apparently they work similarly, but I
don't have any multi-title DVDs for testing. Also, cdda (for audio CDs)
uses the same mechanism as DVDs to report a number of titles, so there
seems to be confusion what exactly this mechanism is supposed to do.
That's why the edition code is completely separate for now.
Remove demuxer.num_titles. It was just a rather useless cache for the
return value of the DVD titles related STREAM_CTRL.
One rather obscure corner case isn't taken care of: if the ordered
chapters file has file local options set, they are reset on playback
restart. This is unexpected, because edition switching is meant to
behave like seeking back to the beginning of the file.
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.
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.
The generic hardware pass-through decoder ad_spdif (imported from
mplayer-svn) was mistakenly prefered over the default decoder mpg123.
This is the same as mplayer-svn commit 34192.
The spidfmpa entry was marked as "untested", which for inconceivable
reasons is preferred over entries marked "working". (The probe order
is untested, working, buggy. Possibly to "force" untested codecs to be
tested?) I didn't know this behavior, and skipped the corresponding
mplayer-svn commit 34192, as it looked like it would move up the entry
in autoprobe order (not the reverse), which might have been slightly
dangerous, or at least not something we would have to bother with.
The only change in behavior the incorrect entry caused was that playing
a shoutcast mp3 stream displayed "inf" as time on the mplayer status
line, instead the time since joining the stream. (The same can be seen
when starting mplayer-svn with -ac spdifmpa,mpg123 .) I'm not sure why
this happens; I can only guess that when spdifmpa throws away header
data when it fails initializing, or messes up something else.
patch by Naoya OYAMA, naoya.oyama gmail com
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34191 b3059339-0415-0410-9bf9-f77b7e298cf2
fix ad_spdif
Call av_register_all() before initialising the SPDIF muxer.
Fixes playback with -demuxer mpegts -ac spdifac3.
Patch by Naoya OYAMA, naoya D oyama gmail
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34291 b3059339-0415-0410-9bf9-f77b7e298cf2
Use new API avformat_new_stream() instead of the deprecated
av_new_stream().
Patch by Naoya OYAMA, naoya D oyama gmail
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34292 b3059339-0415-0410-9bf9-f77b7e298cf2
Cosmetics: Remove empty statement.
Patch by Naoya OYAMA, naoya D oyama gmail
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34293 b3059339-0415-0410-9bf9-f77b7e298cf2
Use init_avformat() instead of av_register_all().
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34294 b3059339-0415-0410-9bf9-f77b7e298cf2
Author: diego
Teletext requires special OSD support. Because I can't even test
teletext, I can't restore support for it. Since teletext can be
considered ancient and obscure, and since it doesn't make sense to keep
the remaining teletext code without being able to use it, I'm removing
it.
This reverts commit c8b0f21154.
This was a very bad idea. It caused A/V desync with some crappy AVI
files, and upon inspecting ad_mad.c, it seems all hope is lost.
Go back to the prefering the mpg123 & libav codecs.
wm4
Rudolf Polzer
Nikoli
Stefano Pigozzi
Alexander Preisinger
James Ross-Gowan
mplayer-svn