Until now, options could be accessed as properties via "options/name",
but the access was read-only. Change it so that write access is possible
in --idle mode. (All options have to support setting options at that
time, simply because of the way MPlayer designed per-file options.
During playback, normal properties take care of changing things,
including things backed by options.)
This is work in progress. There are some issues: at least setting the
"vf" and "af" options won't work for strange reasons.
When enabling --save-position-on-quit, playback position stored not only
on quit, but in any case playback of a file was stopped. This includes
going to the next file with playlist navigation commands.
After some discussion on IRC, it turned out that nobody thought this was
good behavior. Disable it, and really make it save only on quit.
Maybe the option is useless now, as the user could remap the CLOSE_WIN
key binding. On the other hand, CLOSE_WIN sounds and _is_ a bit obscure.
Before this commit, the player didn't write resume info if the playback
position was within the first or last percent of the file.
This was sometimes annoying, and with playlist resume can lead to
unintuitive behavior. (It wouldn't resume the playlist if the currently
played file was at 0-1% or 99-100%, even if you were in the middle of a
playlist.)
Moreover, the "percent > 99" check is a bit bogus anyway, because 100
(in integer) is rarely reached.
Drop the check, and make sure using --save-position-on-quit won't write
resume info when reaching EOF. The latter check is needed to make sure
playback of the file starts at beginning when playing it again after
EOF.
This includes the case of passing multiple files to command line
(internally this is the same as loading a playlist).
Resuming works by finding the first playlist entry that can be resumed.
Alternative implementations would be possible, such as hashing the
playlist contents. But this implementation is simpler, and doesn't have
the disadvantage that changes to the playlist (like appending entries)
will throw away the resume point.
This makes loading large playlists a bit slower, because it has to look
into ~/.mpv/watch_later/ for every entry. Loading a 15000 entries
playlist now increases from 150ms to 400ms. Considering you rarely load
playlists this big with mpv (because it's impractical considering the
terminal and non-GUI nature of the player), this is probably ok.
The option list contains an empty string member with this option value,
so ignore that. I'm not sure whether the option list should maybe be
empty in this case, but it could be the wrong thing in case of other
options.
This happens by default with pausing: if a file was paused when doing
quit_watch_later, then resume and unpause, then the file played after
that would start in paused mode. This is because the pause option is
backed up at thr wrong place, so it backs up the state from resuming,
instead of whatever it was set to before that.
Modeled after the old playlist_parser.c, but actually new code, and it
works a bit differently.
Demuxers (and sometimes streams) are the component that should be used
to open files and to determine the file format. This was already done
for subtitles, but playlists still use a separate code path.
Until now, video output levels (obscure feature, like using TV screens
that require RGB output in limited range, similar to YUY) still required
handling of VOCTRL_SET_YUV_COLORSPACE. Simplify this, and use the new
mp_image_params code. This gets rid of some code. VOCTRL_SET_YUV_COLORSPACE
is not needed at all anymore in VOs that use the reconfig callback. The
result of VOCTRL_GET_YUV_COLORSPACE is now used only used for the
colormatrix related properties (basically, for display on OSD). For
other VOs, VOCTRL_SET_YUV_COLORSPACE will be sent only once after config
instead of twice.
This affects VOs which just reuse the mp_image from draw_image() to
return screenshots. The aspect of these images is never different
from the aspect the screenshots should be, so there's no reason to
adjust the aspect in these cases.
Other VOs still need it in order to restore the original image
attributes.
This requires some changes to the video filter code to make sure that
the aspect in the passed mp_images is consistent.
The changes in mplayer.c and vd_lavc.c are (probably) not strictly
needed for this commit, but contribute to consistency.
Too many people thought "D:" really meant number of dropped frames. But
it's actually the number of frames where the playloop thought it'd be
a good idea to drop them. Of course this does nothing if frame dropping
is disabled, but even with normal frame dropping, this doesn't indicate
whether a frame was _really_ dropped. (Looks like libavcodec doesn't
even give us this information reliably? The decode function can return
no frame in case of codec delay due to threading and such.)
See github issue #194.
Unfortunately, this breaks the property that going back in the playlist
always works as expected. This changes, because the playlist_prev
command will work on the reshuffled playlist, instead of loading the
previously played files in order. If this ever becomes an issue, I
might revert this commit.
Consider:
mpv file1.mkv file2.mkv
and file1.mkv is restored from an earlier session when quit_watch_later
was used. Then all restored options were reset when file2.mkv is played,
even if the user changed them during playback. This affects for example
the fullscreen setting.
Make it so that after finishing a resumed file, the previously restored
settings are not reset again. (Which means only resuming will forcefully
overwrite the settings.)
core is used in many unix systems for core dumps. For that reason some tools
work under the assumption that the file is indeed a core dump (for example
autoconf does this).
This commit just renames the files. The following one will change all the
includes to fix compilation. This is done this way because git has a easier
time tracing file changes if there is a pure rename commit.
