The demux_open as well as demux_open_withparams calls don't use the
stream selection parameters anymore, so remove them everywhere.
Completes the previous commit.
These separate arrays were used by the old demuxers and are not needed
anymore. We can simplify track switching as well.
One interesting thing is that stream/tv.c (which is a demuxer) won't
respect --no-audio anymore. It will probably work as expected, but it
will still open an audio device etc. - this is because track selection
is now always done with the runtime track switching mechanism. Maybe
the TV code could be updated to do proper runtime switching, but I
can't test this stuff.
Delete demux_avi, demux_asf, demux_mpg, demux_ts. libavformat does
better than them (except in rare corner cases), and the demuxers have
a bad influence on the rest of the code. Often they don't output
proper packets, and require additional audio and video parsing. Most
work only in --no-correct-pts mode.
Remove them to facilitate further cleanups.
This commit removes the "old" networking code in favor of libavformat's
code.
The code was still used for mp_http, udp, ftp, cddb. http has been
mapped to libavformat's http support since approximately 6 months ago.
udp and ftp have support in ffmpeg (though ftp was added only last
month). cddb support is removed with this commit - it's probably not
important and rarely used if at all, so we don't care about it.
The entries were always added after the insertion point - but that
means the entries are appended in reverse order. So update the
insertion point on each entry.
Regression introduced by commit 5f664d7.
Update Cocoa parts to remove usage of the mp_fifo internal API to send events
to the core and use the input context directly. This is to follow commits the
work in commits 70a8079c and d603e73c.
For some reason mp_fifo specifically handled double clicks, and other
than that was a pointless wrapper around input.c functionality.
Move the double click handling into input.c, and get rid of mp_fifo. Add
some compatibility wrappers, because so much VO code uses these
functions. Where struct mp_fifo is still used it's just a casted
struct input_ctx.
STREAM_CTRL_GET_METADATA will be used to poll for streamcast metadata.
Also add DEMUXER_CTRL_UPDATE_INFO, which could in theory be used by
demux_lavf.c. (Unfortunately, libavformat is too crappy to read metadata
mid-stream for mp3 or ogg, so we don't implement it.)
Making key up events implicit was sort-of a nice idea, but it's too
tricky and unreliable and makes the key lookup code (interpret_keys())
hard to reason about. See e.g. previous commit for subtle bugs and
issues this caused.
Make key-up events explicit instead. Add key up events to all VOs.
Any time MP_KEY_STATE_DOWN is used, the matching key up event must
use MP_KEY_STATE_UP.
Rewrite the key lookup code. It should be simpler and more robust now.
(Even though the LOC increases, because the new code is less "compact".)
Wayland is the only backend that actually sends per-key key up events
(the X11 one just sends MP_INPUT_RELEASE_ALL for simplicity). Handling
was broken with Wayland, and each key event was interpreted twice, once
on key down and once on key up.
This commit should fix it.
Before this commit, only mouse events with both down and up events
were processed. This caused a regression with ignoring mouse wheel
events in cocoa, because these don't distinguish between up and down.
Regression caused by 5b38a52.
This means the direct libass usage can be removed from command.c, and no
weird hacks for retrieving the ASS_Track are needed.
Also fix a bug when using this feature with ordered chapters.
This was changed as part of commit b44202b as an intended
simplification, but it's actually nicer to have the subtitles
update immediately even if paused.
Instead mark individual key bindings as builtin.
Not sure whether this is conceptually simpler or more complicated.
For one, it requires the annoying remove_binds() function to wipe
existing bindings instead of just killing the section, on the other
hand it gets rid of almost all special handling of builtin vs. normal
sections.
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.)
percent-pos was an integer (0-100). Sometimes higher precision is
wanted, but the property is this way because fractional parts would
look silly with normal OSD usage. As a compromise, make percent-pos
double (i.e. includes fractional parts), but print it as integer.
So ${percent-pos} is like an integer, but not ${=percent-pos}.
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.
Should we actually get into trouble for unproper handling of
frame-based subtitle formats, this might be the simplest way to
work this around. Also is a bit more intuitive than -subfps, which
might use an unknown, misdetected, or non-sense video FPS.
Still pretty silly, though.
This code was once part of subreader.c, then traveled to libass, and now
made its way back to the fork of the fork of the original code, MPlayer.
It works pretty much the same as subreader.c, except that we have to
concatenate some packets to do auto-detection. This is rather annoying,
but for all we know the actual source file could be a binary format.
Unlike subreader.c, the iconv context is reopened on each packet. This
is simpler, and with respect to multibyte encodings, more robust.
Reopening is probably not a very fast, but I suspect subtitle charset
conversion is not an operation that happens often or has to be fast.
Also, this auto-detection is disabled for microdvd - this is the only
format we know that has binary data in its packets, but is actually
decoded to text. FFmpeg doesn't really allow us to solve this properly,
because a) the input packets can be binary, and b) the output will be
checked whether it's UTF-8, and if it's not, the output is thrown away
and an error message is printed. We could just recode the decoded
subtitles before sd_ass if it weren't for that.
demux_libass.c allows us to make subtitle format detection part of the
normal file loading process. libass has no probe function, but trying to
load the start of a file (the first 4 KB) is good enough. Hope that
libass can even handle random binary input gracefully without printing
stupid log messages, and that the libass parser doesn't accept too many
non-ASS files as input.
This doesn't handle the -subcp option correctly yet. This will be fixed
later.
The default correct-pts mode depended on which demuxer was opened last.
Often this is the subtitle demuxer. The correct-pts mode should be
decided on the demuxer for video instead.
subreader.c (before this commit renamed to demux_subreader.c) was
special cased to the -sub option. The plan is using the normal demuxer
codepath for all subtitle formats (so we can prefer libavformat demuxers
for most formats).
There are some subtle changes. The probe size is restricted to 32 KB
(instead of unlimitted + giving up after 100 lines of input). For
formats like MicroDVD, the video FPS isn't used anymore, because it's
not available on the subtitle demuxer level. Instead, hardcode it to
23.976 FPS (libavformat seems to do the same). The user can probably
still use -sub-fps to fix the timing. Checking the file extension for
".utf"/".utf8"/".utf-8" is simply removed (seems worthless, was in the
way, and I've never seen this anywhere).
This fixes the -subfps option (which unfortunately is still useful),
and fixes minor annoying timing errors (which unfortunately still
happen).
Note that none of these affect ASS or image subtitles. ASS is specially
handled: libass loads subtitles as ASS_Track. There are no actual
packets passed around, and sd_ass just uses the ASS_Track.
Disable the --sub-no-text-pp option. It's misleading now and always was
completely useless.
If a subtitle is external, read it completely and add all subtitle
events in advance when the subtitle track is selected. This is done
for text subtitles only. (Note that subreader.c and subtitles loaded
with libass are different and don't have anything to do with this
commit.)
Seems like a completely unnecessary complication. Instead, always add a
1 byte padding (could be extended if a caller needs it), and clear it.
Also add some documentation. There was some, but it was outdated and
incomplete.
Don't print the ffmpeg context pointer as %p. This is usually useless
and confusing. Prefix all messages with "ffmpeg" to make clear that
ffmpeg is printing these messages, and not us.
If libavcodec is from Libav, use "libav" as prefix instead. (In theory,
FFmpeg/Libav libraries could be mixed, but I don't think that is
actually possible in practice.)
Basically rewrite all the code supporting the cache (i.e. anything other
than the ringbuffer logic). The underlying design is untouched.
Note that the old cache2.c (on which this code is based) already had a
threading implementation. This was mostly unused on Linux, and had some
problems, such as using shared volatile variables for communication and
uninterruptible timeouts, instead of using locks for synchronization.
This commit does use proper locking, while still retaining the way the
old cache worked. It's basically a big refactor.
Simplify the code too. Since we don't need to copy stream ctrl args
anymore (we're always guaranteed a shared address space now), lots of
annoying code just goes away. Likewise, we don't need to care about
sector sizes. The cache uses the high-level stream API to read from
other streams, and sector sizes are handled transparently.
Before this commit, the cache was franken-hacked on top of the stream
API. You had to use special functions (like cache_stream_fill_buffer()
instead of stream_fill_buffer()), which would access the stream in a
cached manner.
The whole idea about the previous design was that the cache runs in a
thread or in a forked process, while the cache awa functions made sure
the stream instance looked consistent to the user. If you used the
normal functions instead of the special ones while the cache was
running, you were out of luck.
Make it a bit more reasonable by turning the cache into a stream on its
own. This makes it behave exactly like a normal stream. The stream
callbacks call into the original (uncached) stream to do work. No
special cache functions or redirections are needed. The only different
thing about cache streams is that they are created by special functions,
instead of being part of the auto_open_streams[] array.
To make things simpler, remove the threading implementation, which was
messed into the code. The threading code could perhaps be kept, but I
don't really want to have to worry about this special case. A proper
threaded implementation will be added later.
Remove the cache enabling code from stream_radio.c. Since enabling the
cache involves replacing the old stream with a new one, the code as-is
can't be kept. It would be easily possible to enable the cache by
requesting a cache size (which is also much simpler). But nobody uses
stream_radio.c and I can't even test this thing, and the cache is
probably not really important for it either.
The core didn't use these fields, and use of them was inconsistent
accross AOs. Some didn't use them at all. Some only set them; the values
were completely unused by the core. Some made full use of them.
Remove these fields. In places where they are still needed, make them
private AO state.
Remove the --abs option. It set the buffer size for ao_oss and ao_dsound
(being ignored by all other AOs), and was already marked as obsolete. If
it turns out that it's still needed for ao_oss or ao_dsound, their
default buffer sizes could be adjusted, and if even that doesn't help,
AO suboptions could be added in these cases.
Currently every single AO was implementing it's own ringbuffer, many times
with slightly different semantics. This is an attempt to fix the problem.
I stole some good ideas from ao_portaudio's ringbuffer and went from there.
The main difference is this one stores wpos and rpos which are absolute
positions in an "infinite" buffer. To find the actual position for writing /
reading just apply modulo size.
The producer only modifies wpos while the consumer only modifies rpos. This
makes it pretty easy to reason about and make the operations thread safe by
using barriers (thread safety is guaranteed only in the Single-Producer/Single-
Consumer case).
Also adapted ao_coreaudio to use this ringbuffer.
This allows having properties like time-pos in the window title update
properly. There is a danger of this causing significant CPU usage,
depending on the properties used and the window manager.
Instead of implicitly changing the window title on config(), do it as
part of the new VOCTRL.
At first I wanted to make all VOs use the VOCTRL argument directly, but
on a second thought it appears vo_get_window_title() is much more useful
for some (namely, if the window is created lazily on first config()).
Not all VOs are changed. Wayland and OSX have to follow.
%k is not very standard. The manpage notes them as conforming to
"Olson's timezone package", and it's not standard C89, C99 or POSIX.
mingw doesn't provide it, and even some of the smaller Linux libcs
don't have support.
Use %H instead. This gives slightly different results, but I think
this is ok. Difference in behavior between these summarized:
%k: "single digits are preceded by a blank"
%H: "range 00 to 23"
Use the recently introduced screensaver VOCTRLs to control the
screensaver in the X11 backend. This means the behavior when paused
changes: the old code always kept the screensaver disabled, but now the
screensaver is reenabled on pausing.
Rename the --stop-xscreensaver option to --stop-screensaver and make it
more generic. Now it affects all backends that respond to the
screensaver VOCTRLs.
This is slightly better because VOCTRL_RESUME/VOCTRL_PAUSE are usually
needed by VOs to know whether video is actually being played (for
whatever reason), and they wouldn't be passed to the backend's VOCTRL
handler, like vo_x11_control().
Also try to make sure that these flags (both pause state and screensaver
state) are set consistently in some corner cases. For example, it seems
enabling video in the middle of playing a file while the player is
paused would not set the paused flag.
If codec initialization fails, destroy the VO instead of keeping it
around to make sure the state is consistent.
Framestepping is implemented by unpausing the player for the duration of
a frame. Remove the special handling of VOCTRL_PAUSE/RESUME in these
cases. It was most likely needed because these VOCTRLs used to be
important for screen redrawing (blatant guess), which is now handled
completely differently. The only potentially bad side-effect is that the
screensaver will be disabled/reenabled for the duration of one frame.
This workaround sucks. avio just does not support "-" - and ffmpeg's
command line binaries work around it. FOUR TIMES. DIFFERENTLY.
WHY DOESN'T AVIO DO THIS RIGHT TO BEGIN WITH?
Whatever this was supposed to be originally, it doesn't have much value
anymore. It just forced ad_mpg123 to upmix mono to stereo by default
(the audio chain can do that). As an option, it was mostly useless and
misleading, so get rid of it.
Raw MPEG streams can contain PTS discontinuities. While the playback
core has obvious code for handling PTS going backward, PTS going
forward was as far as I can see not handled.
This can be an issue with DVD playback. This wasn't caught earlier,
because DVD playback was just recently switched to demux_lavf, which
implies -no-correct-pts mode. This mode doesn't use PTS in the same way
as the normal playback mode, and as such was too primitive to be
affected by this issue.
Use the following heuristic to handle PTS forward jumps: if the PTS
difference between two frames is higher than 10 seconds, consider it a
reset. (Also, use MSGL_WARN for the PTS discontinuity warnings.)
In this particular case, the MPEG stream was going from pts=304510857
to pts=8589959849 according to ffprobe (raw timestamps), which seems a
bit strange.
Note that this heuristic breaks if the source video has unusually high
frame times. For example Rooster_Teeth_Podcast_191.m4a, an audio file
with a slide show encoded as MJPEG video track.
Some code in mplayer.c did stuff like accessing (dvd_priv_t *)st->priv.
Do this indirectly by introducing STREAM_CTRL_GET_DVD_INFO. This is
extremely specific to DVD, so it's not worth abstracting this further.
This is a preparation for turning the cache into an actual stream, which
simply wraps the cached stream. There are other streams which are
accessed in the way DVD was, at least TV/radio/DVB. We assume these
can't be used with the cache. The code doesn't look thread-safe or fork
aware.
show_chapters, show_tracks, and show_playlist are killed and replaced
with the properties chapter-list, track-list, and playlist. The code
and the output of these stays the same, this is just moving a lot of
code around and reducing the number of properties.
The "old" commands will still be supported for a while (to avoid making
everyone angry), so handle them with the legacy layer. Add something to
suppress printing the legacy warnings for these commands.
Slightly better output when printing ${metadata}. Print each metadata
item as "name: value", instead of the raw list. It's still not very
great, though. The old format is still available through ${=metadata}
for things which dare to use the broken slave mode.
This adds a the property 'clock', which returns the current
local time as the string hh:mm.
Additionally the keybinding 'shift' + 'o' was added to displaying
the clock as '[hh:mm]' .
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.
This branch heavily refactors the subtitle code (both loading and
rendering), and adds support for a few new formats through FFmpeg.
We don't remove any of the old code yet. There are still some subtleties
related to subreader.c to be resolved: code page detection & conversion,
timing post-processing, UTF-16 subtitle support, support for the -subfps
option. Also, SRT reading and loading ASS via libass should be turned
into proper demuxers. (SRT is needed because Libav's is gravely broken,
and we want ASS loading via libass to cover full libass format support.
Both should be demuxers which are probed _before_ libavformat, so that
all subtitles can be loaded through the demuxer infrastructure, and
libavformat subtitles don't need to be treated in a special way.)
Until now, this happened only when the -no-ass option was used. This
difference in behavior doesn't make much sense, so change it so that
whether -no-ass is used or not doesn't matter. (-no-ass enables the OSD
subtitle renderer, which has the terminal fallback, while the normal
path is video only.)
the changes in set_osd_subtitle() and reinit_video_chain() are for
resetting the state correctly when switching between video/no-video.
Audio and video had their own (very similar) functions to initialize an
AVPacket (ffmpeg's packet struct) from a demux_packet (mplayer's packet
struct). Add a common function for these.
Also use this function for sd_lavc_conv. This is actually a functional
change, as some libavfilter subtitle demuxers add weird out-of-band
stuff as side-data.
Before this, subtitle packets were returned as data ptr/len pairs, and
mplayer.c got the rest (pts and duration) directly from the demuxer
data structures. Then mplayer.c reassembled the packet data structure
again.
Pass packets directly instead. The mplayer.c side stays a bit awkward,
because the (now by default unused) DVD path keeps getting in the way.
In demux.c there's lots of weird stuff (3 functions that read packets,
really?), but we want to keep the code equivalent for now to avoid
hitting weird issues and corner cases.
The -no-ass option used to disable all use of libass completely. This
doesn't work this way anymore, and the text subtitle path has an
inherent dependency on libass. Currently -no-ass does 3 things:
1. Strip tags and formatting on display, and use a separate renderer for
the result. (Which might be the terminal, or libass via OSD code.)
2. Not loading attached fonts from Matroska files.
3. Use subreader.c instead of libass for reading .ass files.
1. and 2. are ok and what the user (probably wants), but 3. doesn't
really make sense anymore. subreader.c reads .ass files just fine, but
then does some strange things to them (something about coalescing and
re-adding newlines?), leading to even more broken display with -no-ass.
Instead of fighting with subreader.c, just use libass as loader.
This means subassconvert.c is split in sd_srt.c and sd_microdvd.c. Now
this code is involved in the sub conversion chain like sd_movtext is.
The invocation of the converter in sd_ass.c is removed.
This requires some other changes to make the new sub converter code work
with loading external subtitles. Until now, subtitles loaded via
subreader.c was assumed to be in plaintext, or for some formats, in ASS
(except in -no-ass mode). Then these were added to an ASS_Track. Change
this so that subtitles are always in their original format (as far as
decoders/converters for them are available), and turn every sub event
read by subreader.c as packet to the dec_sub.c subtitle chain.
This removes differences between external/demuxed and -ass/-no-ass code
paths further.
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.
On OSX with Cocoa enabled keyDown events are now handled with
addLocalMonitorForEventsMatchingMask:handler:. This allows to respond to
events even when there is no VO initialized but the GUI is focused.
Add a basic infrastructure for subtitle converters. These converters
work sort-of like decoders, except that they produce packets instead
of subtitle bitmaps. They are put in front of actual decoders.
Start with sd_movtext. 4 lines of code are blown up to a 55 lines file,
but fortunately this is not going to be that bad for the following
converters.
OPT_STRING_VALIDATE actually did nothing. This made -vo opengl crash or
misbehave when passing an invalid value for the lscale, cscale or 3dlut-
size (the only users for this option type).
The code added with this commit was either blatantly forgotten with the
commit introducing this option type, or somehow lost.
Make the sub decoder stuff independent from sh_sub (except for
initialization of course). Sub decoders now access a struct sd only,
instead of getting access to sh_sub. The glue code in dec_sub.c is
similarily independent from osd.
Some simplifications are made. For example, the switch_id stuff is
unneeded: the frontend code just has to make sure to call osd_changed()
any time subtitles are switched.
This is also preparation for introducing subtitle converters. It's much
cleaner to completely separate demuxer header/renderer glue/decoders
for this purpose, especially since sub converters might completely
change how demuxer headers have to be interpreted.
Also pass data as demux_packets. Currently, this doesn't help much, but
libavcodec converters might need scary stuff like packet side data, so
it's perhaps better to go with passing packets.
Subtitle files are opened in mplayer.c, not using the demuxer
infrastructure in general. Pretend that this is not the case (outside of
the loading code) by opening a pseudo demuxer that does nothing. One
advantage is that the initialization code is now the same, and there's
no confusion about what the difference between track->stream,
track->sh_sub and mpctx->sh_sub is supposed to be.
This is a bit stupid, and it would be much better if there were proper
subtitle demuxers (there are many in recent FFmpeg, but not Libav). So
for now this is just a transition to a more proper architecture. Look
at demux_sub like an artifical limb: it's ugly, but don't hate it - it
helps you to get on with your life.
This unifies the subtitle rendering path. Now all subtitle rendering
goes through sd_ass.c/sd_lavc.c/sd_spu.c.
Before that commit, the spudec.h functions were used directly in
mplayer.c, which introduced many special cases. Add sd_spu.c, which is
just a small wrapper connecting the new subtitle render API with the
dusty old vobsub decoder in spudec.c.
One detail that changes is that we always pass the palette as extra
data, instead of passing the libdvdread palette as pointer to spudec
directly. This is a bit roundabout, but actually makes the code simpler
and more elegant: the difference between DVD and non-DVD dvdsubs is
reduced.
Ideally, we would just delete spudec.c and use libavcodec's DVD sub
decoder. However, DVD playback with demux_mpg produces packets
incompatible to lavc. There are incompatibilities the other way around
as well: packets from libavformat's vobsub demuxer are incompatible to
spudec.c. So we define a new subtitle codec name for demux_mpg subs,
"dvd_subtitle_mpg", which only sd_spu can decode.
There is actually code in spudec.c to "assemble" fragments into complete
packets, but using the whole spudec.c is easier than trying to move this
code into demux_mpg to fix subtitle packets.
As additional complication, Libav 9.x can't decode DVD subs correctly,
so use sd_spu in that case as well.
It appears demux_mpg doesn't output timestamps for subtitles. The vobsub
code handled this by doing its own PTS calculations. This code is absent
from the normal subtitle decoder path. Copy this code into the normal
path, so that we can unify the subtitle decoder paths in a later commit.
Decoding subtitles with sd_lavc when playing DVD with demux_mpg still
doesn't work.
The -no-ass switch used to disable any use of libass for text subtitles.
This is not really the case anymore, because libass is now always
involved when rendering text. The only remaining use of -no-ass is
disabling styling or showing subtitles on the terminal. On the other
hand, the old subtitle rendering path is a big reason why the subtitle
code is still a big mess with an awful number of obscure special cases.
In order to simplify it, remove the old subtitle rendering code, and
always go through sd_ass.c. Basically, we use ASS_Track as central data
structure for storing text subtitles instead of struct sub_data. This
also makes libass mandatory for all text subs, even if they are printed
to the terminal in -no-video mode. (We could add something like sd_text
to avoid this, but it's not worth the trouble.)
struct sub_data and subreader.c are still around, even its ASS/SSA
reader. But struct sub_data is freed right after converting it to
ASS_Track. The internal ASS reader actually can handle some obscure
cases libass can't, like files encoded in UTF-16.
The core deselected all streams on initialization, and then selected the
streams it actually wanted. This was no problem for
demux_mkv/demux_lavf, but old demuxers (like demux_asf) could lose some
packets. The problem is that these demuxers can buffer some data on
initialization, which then is flushed on track switching. Fix this by
explicitly avoiding deselecting a wanted stream.
Most of these are rather questionable, the rest you rarely need to set
manually. You still can set all of them with -lavdopts-o (because
libavcodec has AVOptions for them).
Playing something with "mpv f1.mkv f2.mkv --gapless-audio --volume=20"
caused the volume to be reset when playing a new file. Normally, the
volume should not be reset (unless explicitly requested with per-file
options), and without either --gapless-audio or --volume it works as
expected.
The underlying problem is that volume was saved only when the AO was
uninitialized, and also the volume was always set when starting a file.
Fix this by saving the volume when playback ends, and when the audio
is reinitialized. To make sure the volume is never restored twice or
saved in the wrong situation, introduce INITIALIZED_VOL.
Also note that this volume saving and restoring only happens if the
--volume option is used. mixer.c does its own bookkeeping of volume.
The main reason for this is that the volume option could be reset by
per-file options (see manpage), and mixer.c doesn't know anything
about this stuff. This is probably dumb, and maybe some things could
be simplified. But for now this will work.
When AAC is streamed over HTTP, using libavformat defaults is
pathetically slow. One solution for that is skipping probing and using
the mimetype to identify that it's AAC instead. This is what we did
before this commit (and ffmpeg does it too, but their logic is too
"inaccessible" for mpv).
This is still pretty fragile though. Make it a bit more robust by
requiring minimal probing. A probescore of 25 is reached after feeding
2 KB to libavformat (instead of > 500 KB for the normal probescore), so
use that. This is done only when streaming AAC from HTTP to reduce the
possibility of weird breakages for other formats.
Also reduce analyzeduration. The default analyzeduration will make
libavformat read lots of data, which makes playback start slow. So we
set analyzeduration to a low value. On the other hand, doing that for
other formats is risky, because there are unspecified effects with
certain "strange" formats (like transport streams). So we do this only
if we're streaming AAC from HTTP as well.
tl;dr libavformat is shit for media players
This can control whether demux_lavf should use the HTTP mime type to
determine the format, instead of probing the data with the libavformat
API. Do this to allow easier debugging in case the mimetype is
incorrect. (This is done only for AAC streams right now.)
In commit 0e07189, I made the status line always print a newline,
instead of cutting the output at 80 columns (or if stderr is a terminal,
whatever width the terminal reports). This is better in the case the
output goes into a log file or a pipe.
This caused problems for people who want to pipe raw video to mpv, so
change it again. (Not sure why they won't use FIFOs instead.)
Now output untrimmed lines if the slave mode flag is set, which makes
sense to do, too. The current slave mode is still on life support,
though.
GetTimer() is generally replaced with mp_time_us(). Both calls return
microseconds, but the latter uses int64_t, us defined to never wrap,
and never returns 0 or negative values.
GetTimerMS() has no direct replacement. Instead the other functions are
used.
For some code, switch to mp_time_sec(), which returns the time as double
float value in seconds. The returned time is offset to program start
time, so there is enough precision left to deliver microsecond
resolution for at least 100 years. Unless it's casted to a float
(or the CPU reduces precision), which is why we still use mp_time_us()
out of paranoia in places where precision is clearly needed.
Always switch to the correct time. The whole point of the new timer
calls is that they don't wrap, and storing microseconds in unsigned int
variables would negate this.
In some cases, remove wrap-around handling for time values.
This was used by some VOs to do timing of cursor autohiding, but we
recently moved that out of the VOs. Even though this mechanism might
be a good idea and could be needed again in future (but for what?),
it's unused now. So better just get rid of it.
Make OS specific timer code export a mp_raw_time_us() function, and
add generic implementations of GetTimer()/GetTimerMS() using this
function. New mpv code is supposed to call mp_time_us() in situations
where precision is absolutely needed, or mp_time_s() otherwise.
Make it so that mp_time_us() will return a value near program start.
We don't set it to 0 though to avoid confusion with relative vs.
absolute time. Instead, pick an arbitrary offset.
Move the test program in timer-darwin.c to timer.c, and modify it to
work with the generic timer functions.
If VO deinterlacing is unavailable, try to insert vf_yadif.
If vf_lavfi is available, actually use vf_yadif from libavfilter. The
libavfilter version of this filter is faster, more correct, etc., so it
is preferred. Unfortunately vf_yadif obviously doesn't support
VFCTRL_GET/SET_DEINTERLACE, and with the current state of the
libavfilter API, it doesn't look like there is any simple way to
emulate it. Instead, we simply insert the filter with a specific label,
and if deinterlacing is to be disabled, the filter is removed again by
label.
This won't do the right thing if the user inserts any deinterlacing
filter manually (except native vf_yadif, which understands the VFCTRL).
For example, with '-vf lavfi=yadif', pressing 'D' (toggle deinterlacing)
will just insert a second deinterlacer filter. In these cases, the user
is supposed to map a command that toggles his own filter instead of
using 'D' and the deinterlace property.
The same applies if the user wants to pass different parameters to the
deinterlacer filters.
If a complete filter description is passed to -vf-del, search for an
existing filter with the same label or the same name/arguments, and
delete it. The rules for filter entry equality are the same as with
the -vf-toggle option.
E.g.
-vf-add gradfun=123:gradfun=456
-vf-del gradfun=456
does what you would expect.
Can be used to refer to filters by name. Intended to be used when the
filter chain is changed at runtime.
A label can be assigned to a filter by prefixing it with '@name:', where
'name' is an user-chosen identifier. For example, a filter added with
'-vf-add @label1:gradfun=123' can be removed with '-vf-del @label1'.
If a filter with an already existing label is added, the existing filter
is replaced with the new filter (this happens for both -vf-add and
-vf-pre). If a filter is replaced, the new filter takes the position of
the old filter, instead of being appended/prepended to the filter chain
as usual. For -vf-toggle, labels are compared if at least one of the
filters has a label; otherwise they are compared by filter name and
arguments (like before). This means two filters are never considered
equal if one has a label and the other one does not.
This prefers ./ on Windows if-and-only-if the file being searched for
already exists there. (If the mpv directory is non-writable, the result
is still intended behavior.) This change is transparent to most users
because the user has to move the config files there intentionally, and
if anything, not being detected would be the surprising behavior.
In the long run this should be done differently. ID_... output sucks.
This commit will be reverted as soon as I have a good idea how this
should be done properly.
The vf-toggle option parsing (normally used for runtime video filter
switching only) was missing comparing the parameter values. Fix this,
and also make the code a bit more robust.
Also add a "raw" prefix for commands, which prevents property expansion.
The idea is that if the commands are generated by a program, it doesn't
have to know whether the command expands properties or not.
This is more consistent, and doesn't bother the user with ordering
rules when new prefixes are added.
Will break obscure uses of legacy commands: if the command is supposed
to be translated by the legacy command bridge, and if that command uses
one of the pausing* prefixes, the command can't be parsed. Well, just
use the new commands in this case.
Add the "vf" command, which allows changing the video filter chain at
runtime. For example, the 'y' key could be bound to toggle deinterlacing
by adding 'y vf toggle yadif' to the input.conf.
Reconfiguring the video filter chain normally resets the VO, so that it
will be "stuck" until a new video frame is rendered. To mitigate this, a
seek to the current position is issued when the filter chain is changed.
This is done only if playback is paused, because normal playback will
show an actual new frame quickly enough.
If vdpau hardware decoding is used, filter insertion (whether it fails
or not) will break the video for a while. This is because vo_vdpau
resets decoding related things on vo_config().
With the current semantics, there's no reason to disallow this.
(Although in my opinion, -vf should rather map to -vf-add than -vf-set,
however that is an independent issue from this change.)
Works like -vf-add, except if a filter already exists and has the same
parameters, it's removed instead of added.
Not really useful on the command line itself, but will make sense for
runtime filter changing in the following commit.
Until now, -vf-del required a list of indexes. This was a bit
inconvenient, so add support for using filter names too. Also simplify
the code a bit, doing the change would have been too painful otherwise.
The main() function is special, and omitting the return statement would
make it always return 0. And also, mpv_main() actually never returns, it
calls exit() through exit_player() instead. But change it anyway,
because it looks misleading.
Apparently useful for dumping DVD. Could also be used to rip streams
with libquvi and such, but for that there are better tools. Actually
I doubt there aren't better tools to dump DVDs, but whatever, this was
a feature request, so I don't need a good reason.
This helps passing the channel layout correctly from decoder to audio
filter chain. (Because that part "reuses" the demuxer level codec
parameters, which is very disgusting.)
Note that ffmpeg stuff already passed the channel layout via
mp_copy_lav_codec_headers(). So other than easier dealing with the
demuxer/decoder parameters mess, there's no real advantage to doing
this.
Make the --channels option accept a channel map. Since simple numbers
map to standard layouts with the given number of channels, this is
downwards compatible. Likewise for demux_rawaudio.
This actually breaks audio for 5/6/8 channels. There's no reordering
done yet. The actual reordering will be done inside of af_lavrresample
and has to be made part of the format negotiation.
wm4
Stefano Pigozzi
Rudolf Polzer
John Hawthorn
Jan-Marek Glogowski
elevengu
Paul B Mahol