| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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().
|
| |
|
|
| |
Basically a cosmetic change. Fixes github issue #88.
|
| |
|
|
|
|
|
| |
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 is a partial revert of commit 7059c15, and basically re-adds
--capture, just with different option names and slightly different
semantics.
|
| |\
| |
| |
| |
| | |
Conflicts:
audio/out/ao_lavc.c
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| | |
Also rename --a52drc to --ad-lavc-ac3drc, and add --ad-lavc-o.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Switch the internal channel order to libavcodec's. If the channel number
mismatches at some point, use libavresample for up- or downmixing.
Remove the old af_pan automatic downmixing.
The libavcodec channel order should be equivalent to WAVEFORMATEX order,
at least nowadays. reorder_ch.h assumes that WAVEFORMATEX and libavcodec
might be different, but all defined channels have the same mappings.
Remove the downmixing with af_pan as well as the channel conversion with
af_channels from af.c, and prefer af_lavrresample for this. The
automatic downmixing behavior should be the same as before (if the
--channels option is set to 2, which is the default, the audio output
is forced to 2 channels, and libavresample does all downmixing).
Note that mpv still can't do channel layouts. It will pick the default
channel layout according to the channel count. This will be fixed later
by passing down the channel layout as well.
af_hrtf depends on the order of the input channels, so reorder to ALSA
(for which this code was written). This is better than changing the
filter code, which is more risky.
ao_pulse can accept waveext order directly, so set that as channel
mapping.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This commit is a followup on the previous one and uses a solution I like more
since it totally decouples the Cocoa code from mpv's core and tries to emulate
a generic Cocoa application's lifecycle as much as possible without fighting
the framework.
mpv's main is executed in a pthread while the main thread runs the native cocoa
event loop.
All of the thread safety is mainly accomplished with additional logic in
cocoa_common as to not increase complexity on the crossplatform parts of the
code.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Schedule mpv's playloop as a high frequency timer inside the main Cocoa event
loop. This has the benefit to allow accessing menus as well as resizing the
window without the playback being blocked and allows to remove countless hacks
from the code that involved manually pumping the event loop as well simulating
manually some of the Cocoa default behaviours.
A huge improvement consists in removing NSApplicationLoad. This is a C function
defined in the Cocoa header and implements a minimal OSX application under ther
hood so that you can use the Cocoa GUI toolkit from C/C++ without having to
respect the Cocoa standards in terms of application initialization. This was
bad because the behaviour implemented by NSApplicationLoad was hard to customize
and had several gotchas especially in the menu department.
mpv was changed to be just a nib-less application. All the Cocoa part is still
generated in code but the event handling is now not dissimilar to what is
present in a stock Mac application.
As a part of reviewing the initialization process, I also removed all of
`osdep/macosx_finder_args`. The useful parts of the code were moved to
`osdep/macosx_appication` which has the broaded responsibility of managing the
full lifecycle of the Cocoa application. By consequence the
`--enable-macosx-finder` configure switch was killed as well, as this feature
is always enabled.
Another change the users will notice is that when using a bundle the `--quiet`
option will be inserted much earlier in the initializaion process. This results
in mpv not spamming mpv.log anymore with all the initialization outputs.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Makes it easier to understand... maybe. It's still pretty strange how
this function may either queue the seek or seek immediately. The way
it actually works doesn't change, queuing the seek is just moved into
the function.
Also add a execute_queued_seek() function, which resets the queue state
correctly.
|
| | |
| |
| |
| |
| |
| |
| | |
The frontend doesn't use this.
Also use double for returning the chapter times. Everything uses double
for times, and there's no reason to use float here.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| | |
Move it into its own function.
|
| | |
| |
| |
| |
| |
| | |
Also, mark demuxer as not capable if DVD playback is done. The problem
with DVD is that playback time (stream_pts) is not reported frame-exact,
and the time is a "guess" at best.
|
| | | |
|
| | |
| |
| |
| | |
Also, the trailing space isn't needed.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Rename the struct MPOpts "start_pause" field to "pause". Store the user-
pause state in that field, so that both runtime pause toggling and the
--pause switch change the same variable. Simplify the initialization of
pause so that using --pause and changing the file while paused is
exactly the same case (changing the file while paused doesn't unpause,
this has been always this way).
Also make it a bit more consistent. Before, starting with --pause would
reset the pause state for every file, instead of following the usual
semantics for option switches (compare with behavior of --fs).
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The core pauses and unpauses automatically to wait for the network
cache (also known as buffering). This conflicted with user pause
control, and was perceived as if the player was unresponsive and/or
the cache just overturned the user's decisions.
Change it so that the actual pause state and the pause state as
intended by the user never conflict. If the user toggles pause, the
pause state will be in the expected state as soon as the cache is
loaded.
|
| | |
| |
| |
| |
| | |
This broke all cases where indexing was required, and the current frame
wasn't the first frame in a segment.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
There were two problems.
First, frames past the end of the current segment were added to the
index, which messed up backstepping. Check for the endpts before
added a frame to the index.
Second, it wasn't possible to step over segments which change the file.
Changing a file causes decoder reinitialization, which (rightfully)
is treated as discontinuity (and vo_pts_history_seek_ts was changed).
Add some extra code to pretend that a segment-switching seek/reinit
does not introduce discontinuities.
There's still a weird corner case: sometimes, you can frame step forward
on the last frame of a segment without reaching the next segment
immediately. This is because the playloop switches into audio-only mode.
The segment is switched when both audio and video have ended, so the
frame stepping will play random sized chunks of audio until the segment
will be switched. This gives the impression that backstepping doesn't
work perfectly, even though it's the other way around and frame stepping
behaves weird. This is a consequence of wanting to make frame stepping
work with audio, and is not really a bug.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
It's not sure if there's anything that could trigger this accidentally.
Normally this can't happen, because hrseek ends always if the PTS is
large enough, the same condition which disables framedrop. Seeking
resets hrseek framedrop anyway.
On the other hand, this change makes the code easier to understand,
and might be more robust against weird corner cases.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Before this commit, it was more or less random which subtitle was
preferred if there was both an auto-loaded external subtitle, and a
subtitle loaded via -sub or -subfile. -sub subtitles happened to be
preferred over auto-loaded subs, while -subfile didn't. Fix the -subfile
case, and make the behavior consistent by making the selection behavior
explicit.
|
| | |
| |
| |
| |
| | |
Also switch the subrip and subviewer names, which obviously have been
confused.
|
| | |
| |
| |
| | |
Completely mysterious, and its values were never actually used.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Get rid of the 1-char subtitle type field. Use sh_stream->codec instead
just like audio and video do. Use codec names as defined by libavcodec
for simplicity, even if they're somewhat verbose and annoying.
Note that ffmpeg might switch to "ass" as codec name for ASS, so we
don't bother with the current silly "ssa" name.
|
| |/
|
|
|
|
|
|
|
|
|
| |
With Matroska ordered chapters, the main file (i.e. the file you're
playing) can be empty, while all video/audio data is in linked files.
Some files don't even contain the track list, only chapter information.
mpv refused to play these, because normally, the main file dictates the
track layout.
Fix this by using the first segment for track data if no part of the
timeline is sourced from the main file.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
This option can be used to selectively reset settings when playing the
next file in the playlist (i.e. restore mplayer and mplayer2 behavior).
Might remove this option again should it turn out that nobody uses it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Consider:
mpv --volume 10 file1.mkv file2.mkv
Before this commit, the volume was reset to 10 when playing file2.mkv.
This was inconsistent to most other options. E.g. --brightness is a
rather similar case.
In general, settings should never be reset when playing the next file,
unless the option was explicitly marked file-local. This commit
corrects the behavior of the --volume and --mute options.
File local --volume still works as expected:
mpv --{ --volume 10 file1.mkv file2.mkv --}
This sets the volume always to 10 on playback start.
Move the m_config_leave_file_local() call down so that the mixer code
in uninit_player() can set the option volume and mute variables without
overwriting the global option values.
Another subtle issue is that we don't want to set volume if there's no
need to, which is why the user_set_volume/mute fields are introduced.
This is important because setting the volume might change the system
volume depending on other options.
|
| |
|
|
| |
Try not to cause unnecessary special cases.
|
| |
|
|
| |
I don't see any reason for doing this.
|
| |
|
|
|
| |
When streaming from http, this could print a status line indicating
paused playback instead of "buffering" sometimes.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Makes sure that seeking to a given time position shows the subtitle at
that position. This can fail if the subtitle packet is not close enough
to the seek target. Always enabled for hr-seeks, and can be manually
enabled for normal seeks with --mkv-subtitle-preroll.
This helps displaying subtitles correctly with ordered chapters. When
switching ordered chapter segments, a seek is performed. If the subtitle
is timed slightly before the start of the segment, it normally won't be
demuxed. This is a problem with all seeks, but in this case normal
playback is affected. Since switching segments always uses hr-seeks,
the code added by this commit is always active in this situation.
If no subtitles are selected or the subtitles come from an external
file, the demuxer should behave exactly as before this commit.
|
| |
|
|
|
|
| |
This closely follows MPlayer commit 36099, with some changes.
Move a mutable static variable into MPContext.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The main problem with video PTS |
