Timeline handling converted the pts values from demuxed subtitles to
timeline scale. Change the code to do most subtitle handling in
original subtitle source pts, and instead convert current playback
timeline pts to those units when deciding which subtitle to show.
The main functionality changes are that now demuxed subtitles which
overlap chapter boundaries are handled correctly (at least for libass
subtitles), and external subtitles are assumed to use same pts scale
as current source (this needs improvements later).
Before, a video subtitle that had a duration continuing past the end
of the chapter would continue to be shown for the original duration,
even if the chapter ended and playback switched to a position in the
source where the subtitle shouldn't exist. Now, the subtitle will
correctly end.
Before, external subtitle files were interpreted as specifying pts
values in timeline scale. Now, they're interpreted as specifying pts
values in source file time scale, for _every_ source file. This is
probably more likely to be what the user wants for the "main" source
file in case there is one, but almost certainly not quite right for
multiple source files where the same subs could be shown over
different scenes. If the user wants them to match some main source
file, it's probably still better to have incorrect extra subs for
video from some files than to have every subtitle appearing at the
wrong time. The new code makes it easier to change the interpretation
of the subtitle times, and some configurability should be added in
the future.
When switching to a timeline part from another file, decoders were
reinitialized after doing the demuxer-level seek. This is necessary
for audio because some decoders read from the demuxer stream during
initialization and the previous stream position before seek could have
been at EOF. However, this initialization sequence could lose first
subtitles or first part of audio.
The problem for subtitles was that the seek itself or audio
initialization could already have buffered subtitle packets from the
new position, and the way subtitles are reinitialized flushes packet
buffers. Thus early subtitles could be lost (even if they were demuxed
- unfortunately demuxers may not know about still active subtitles
earlier in the file, but that's another issue). Fix this by moving
subtitle and video reinitialization before the demuxer seek; they
don't have the problems which prevent that for audio.
Audio initialization can already decode and buffer some output.
However, the seek_reset() call done last would then throw away this
buffered output. Work around this by adding an extra flag to
seek_reset().
Restructure parts of the code in the main play loop. The main
functionality difference is that if a video track ends first, now
audio will continue to be played until it ends too.
Now the process also wakes up less often if there's no need to update
video or audio. This will reduce unnecessary wakeups especially when
paused, but may make handling of input events laggier when fd-based
notifications are not supported (like most input on Windows).
Change the terminal status line to show "???" instead of a huge
negative number if audio or video pts is missing (there was a partial
workaround for audio before, but not video or A-V difference).
Remove the old EDL implementation that was activated with the --edl
option. It is mostly redundant and inferior compared to the newer
demux_edl support, though currently there's no support for using the
same EDL files with the new implementation and the mute functionality
of the old implementation is not supported. The main reason to remove
the old implementation at this point is that the mute functionality
would conflict with following audio volume handling changes, and
working on the old code would be a wasted effort in the long run as at
some point it would be removed anyway.
The --edlout functionality is kept for now, even though after this
commit there is no code that could directly read its output.
Windows uses a legacy codepage for char* / runtime functions accepting
char *. Using UTF-8 as the codepage with setlocale() is explicitly
forbidden.
Work this around by overriding the MSVCRT functions with wrapper
macros, that assume UTF-8 and use "proper" API calls like _wopen etc.
to deal with unicode filenames. All code that uses standard functions
that take or return filenames must now include osdep/io.h. stat()
can't be overridden, because MinGW-w64 itself defines "stat" as a
macro. Change code to use use mp_stat() instead.
This is not perfectly clean, but still somewhat sane, and much better
than littering the rest of the mplayer code with MinGW specific hacks.
It's also a bit fragile, but that's actually little different from the
previous situation. Also, MinGW is unlikely to ever include a nice way
of dealing with this.
The _UWIN define causes the mingw headers not to declare deprecated (on
Windows) function names such as open and mkdir. But the code uses these. I
have no idea why this used to work (if it even did), but the original
reason why it was defined seems to have vanished.
The terminal OSD line was written with mp_msg(MSGT_CPLAYER, ...) but
erased with printf(). This meant that disabling MSGT_CPLAYER messages
would prevent the terminal line from being printed, but a line
(probably unrelated) would still be cleared. Change the clearing code
to use mp_msg(MSGT_CPLAYER, ...) too.
The vd_ffmpeg decode() function returned without doing anything if the
input packet had size 0. This meant that flushing buffered frames at
EOF did not work. Remove this test. Have the core code skip such
packets coming from the file being played instead (Libav treats
0-sized packets as flush signals anyway, so better assume such packets
do not represent real frames with any codec).
Remove the private bswap and intreadwrite.h implementations and use
libavutil headers instead.
Originally these headers weren't publicly installed by libavutil at
all. That already changed in 2010, but the pure C bswap version in
installed headers was very inefficient. That was recently (2011-12)
improved and now using the public bswap version probably shouldn't
cause noticeable performance problems, at least if using a new enough
compiler.
Since the recent OSD redraw changes, every GUI expose event causes the
message "===== PAUSE =====" to be printed on console. This was a bit
annoying, so change it so that it is only printed once when going into
paused mode. It's also printed again if the cache status changes (when
playing URLs), or when the status line is printed during pause mode (when
you seek while paused).
This also removes some minor code duplication.
When the OSD was enabled and the player was paused by executing the
frame_step command, the OSD still displayed the icon indicating
playback. Fix this and always set the proper icon when the pause
state is changed.
Remove no longer necessary tests from hrseek code. As a result each
field of vo_vdpau framerate-doubling deinterlace modes is now
considered as a possible seek target.
Remove code refreshing window contents after events such as resize
from vo_vdpau, vo_gl and vo_xv. Instead have them simply set a flag
indicating that a refresh is needed, and have the player core perform
that refresh by doing an OSD redraw. Also add support for updating the
OSD contents over existing frames during slow-but-not-paused playback.
The VOs now also request a refresh if parameters affecting the picture
change (equalizer settings, colormatrix, VDPAU deinterlacing setting).
Even previously the picture was typically redrawn with the new
settings while paused because new OSD messages associated with setting
changes triggered a redraw, but this did not happen if OSD was turned
off.
A minor imperfection is that now window system events can trigger a
single one-frame step forward when using vo_xv after pausing so that
vo_xv does not yet have a copy of the current image. This could be
fixed but I think it's not important enough to bother.
Previously the core sent VFCTRL_REDRAW_OSD to change OSD contents over
the current frame. Change this to VFCTRL_REDRAW_FRAME followed by
normal EOSD and OSD drawing calls, then vo_flip_page(). The new
version supports changing EOSD contents for libass-rendered subtitles
and simplifies the redraw support code needed per VO. vo_xv doesn't
support EOSD changes because it relies on vf_ass to render EOSD
contents earlier in the filter chain.
vo_xv logic is additionally simplified because the previous commit
removed the need to track the status of current and next images
separately (now each frame is guaranteed to become "visible" soon
after we receive it as "next", with no VO code running in the interval
between).
Separate passing a new frame to VOs using the new API into two steps.
The first, vo_draw_image(), happens after a new frame is available
from the filter chain. In constrast to old behavior, now the frame is
not actually rendered yet at this point (though possible slice draw
calls can already reach the VO before). The second step,
vo_new_frame_imminent(), happens when we're close enough to the
display time of the new frame that we'll commit to flipping it as the
next action and will not change the OSD over the previous frame any
more.
This new behavior fixes a previous problem with vo_vdpau and vo_gl in
the situation where the player is paused after decoding a new frame
but before flipping it; previously changing OSD in that state would
switch to the new frame as a side effect. It would also allow an easy
way to fix extra output files produced with something like "--vo=png
--frames=1" with precise seeking, but this is not done yet.
The code now relies on a new mp_image from the filter chain staying
valid even after the vf_vo put_image() call providing it returns. In
other words decoders/filters must not deallocate or otherwise
invalidate their output frame between passing it forward and returning
from the decode/filter call.
Add a VO command (VOCTRL_SCREENSHOT) which requests a screenshot
directly from the VO. If VO support is available, screenshots will be
taken instantly (no more 1 or 2 frames delay). Taking screenshots when
hardware decoding is in use will also work (vdpau). Additionally, the
screenshots will now use the same colorspace as the video display.
Change the central MPContext to be allocated with talloc so that it
can be used as a talloc parent context.
This commit does not yet implement the functionality for any VO (added
in subsequent commits).
The old screenshot video filter is not needed anymore if VO support is
present, and in that case will not be used even if it is present in
the filter chain. If VO support is not available then the filter is
used like before. Note that the filter still has some of the old
problems, such as delaying the screenshot by at least 1 frame.
Some demuxers do not accurately seek to a keyframe before a given
time but instead start too late. This means that precise seeks cannot
work either. Most notably the libavformat mpeg demuxer exhibits this
behavior depending on the file being played (with the internal mpeg
demuxer precise seeks don't work at all). Add new option
--hr-seek-demuxer-offset which can be used as a workaround with such
demuxers. The value of the option is subtracted from the seek target
position given to the demuxer when doing a precise seek.
Before, precise seeking only worked if there was a video stream; in
the audio-only case playback always started from the demuxer seek
position. Add code to cut away samples from the demuxer seek position
to the seek target position.
Information about individual chapters was printed during demuxer
opening phase, and total chapter count (ID_CHAPTERS) was printed
according to mpctx->demuxer->num_chapters. When playing a file with
ordered chapters, this meant that chapter information about every
source file was printed individually (even though only the chapters
from the first file would be used for playback) and the total chapter
count could be wrong. Remove the printing of chapter information from
the demuxer layer and print the chapter information and count actually
used for playback in core print_file_properties().
Also somewhat simplify the internal chapters API and remove possible
inconsistencies.
Something like the OSD menu functionality could be useful. However the
current implementation has several problems and would require a
relatively large amount of work to get into good shape. As far as I
know there are few users of the existing functionality. Nobody is
working on the existing code and keeping it compiling at all while
changing other code would require extra work. So delete the menu code
and some related code elsewhere that's used by nothing else.
Commit dde8b753e4 merged an mplayer1 change (r31328) that set
correct_pts to true if FPS was not set (on the assumption that
correct-pts mode could provide proper timing without FPS). As the
merge commit noted this change was somewhat questionable, as the
option shouldn't really change after things have already been
initialized. After recent changes it can cause an outright crash
(assert in ds_get_packet2() from 9c7c4e5b7d fails). Remove the hack.
Also only print a warning about not having FPS if correct_pts is not
set (in correct_pts mode not having FPS shouldn't be a real problem,
as everything is based on timestamps anyway).
Pass the libavformat packet side_data field from demux_lavf to
vd_ffmpeg. Libavcodec/libavformat use this field for palette data, and
passing it is required for the playback of some paletted video codecs.
The implementation works by giving vd_ffmpeg a copy of the struct
demux_packet used to store the video packet (from which it can access
the avpacket field). The definition of struct demux_packet is moved to
new file demux_packet.h so that vd_ffmpeg.c can use it without
including all of demuxer.h.
The committed version of 58834653c0 ("dvdnav: make
mp_dvdnav_save_smpi() more robust") was somehow missing one line which
caused a crash with dvdnav. Add it back.
The OSD text buffers (mp_osd_msg_t.text and osd_state.text) used to be
static arrays, with the buffer sizes spread all over the code as magic
constants. Make the buffers dynamically allocated and remove the
arbitrary length limits.
Remove outdated "!mpctx->sh_video" checks in chapter seeking and
naming functions left over from when timeline functionality did not
support audio-only case.
I had delayed reformatting mplayer.c as I wanted to split it, but
since I didn't come up with a good way to do that I'll clean up the
messy formatting now.
Initialize mpctx->last_chapter_seek to -2 instead of -1. This changes
get_current_chapter() return value to -2 for files which have no
chapters. -2 is used by some commands related to chapters to recognize
files without chapters and return failure without any effect in that
case.
Seeking while paused could result in the current audio pts being
reported incorrectly due to relevant variables not being reinitialized
after the seek until more audio was played. When playing audio-only
files, this meant that current overall playback position could be
reported incorrectly which in turn could break further seeks. Improve
things on two levels: First, store the seek target position and use
that as the current playback position for audio-only files until
things can be reinitialized. Second, try to reinitialize audio
decoding enough to know its current pts even while paused. Also avoid
printing the actual huge negative value of MP_NOPTS_VALUE on the
status line when pts could not be determined.
Change written_audio_pts() and playing_audio_pts() to return
MP_NOPTS_VALUE if no reasonable pts estimate is available. Before they
returned some incorrect value typically around zero (but not
necessarily exactly that).
Allow writing commandline options with two leading dashes. In this
mode a parameter for the option, if any, follows after a '=';
following separate commandline arguments are never consumed as a
parameter to a previous double-dash option.
Flag options may omit parameter and behave like old single-dash
syntax. "--fs=yes", "--fs=no" and "--fs" are all valid; the first two
behave like configuration file "fs=yes" and "fs=no", and last is the
same as old "-fs" (same effect as "--fs=yes").
Make per-file loop option start from --ss position, not always 0.
Do looping in more cases; before looping was only done when
encountering real end of file, now it also happens for example at
--endpos or --frames limits. Also move the --ss option to the option
struct.
The --ass-force-style option was only applied when the main libass
library handle was created. Thus any per-file option changes later had
no effect. Do the ass_set_style_overrides() call in per-file
initialization instead so that possible changes will be applied. Also
move the option variable to the option struct.
Current libass will crash (usually) if you set style overrides to a
nonempty value, then an empty one. It'll be easier to trigger this bug
after this commit, but the problem is not on mplayer2 side. The fix is
trivial so hopefully there will be a fixed libass soon.
Do the global initialization of libavcodec and libavformat
(avcodec_register_all(), av_register_all()) immediately on program
startup and remove the initialization calls from various individual
modules that use libavcodec/libavformat functionality.
Setting O_NONBLOCK on a file descriptor also affects all other fds
that share the same underlying open file description, and in case of
stdin such sharing is likely. Making stdin nonblocking can also make
stdout nonblocking (they may be the same connection to a terminal),
and it can also affect other processes (in "program1 | program2", the
shell may give the same terminal connection to program1 as stdin and
to program2 as stdout, thus program1 making its stdin nonblocking also
turns program2's stdout nonblocking).
To avoid these problems stop making fd 0 nonblocking. After the
previous commit this should no longer cause problems as long as
select() does not spuriously report the fd as readable.
Rework much of the logic related to reading from event sources and
queuing commands. The two biggest architecture changes are:
- The code buffering keycodes in mp_fifo.c is gone. Instead key input
is now immediately fed to input.c and interpreted as commands, and
then the commands are buffered instead.
- mp_input_get_cmd() now always tries to read every available event
from every event source and convert them to (buffered) commands.
Before it would only process new events until one new command became
available.
Some relevant behavior changes:
- Before commands could be lost when stream code called
mp_input_check_interrupt() which read commands (to see if they were
of types that triggered aborts during slow IO tasks) and then threw
them away. This was especially an issue if cache was enabled and slow
to read. Fixed - now it's possible to check whether there are queued
commands which will abort playback of the current file without
throwing other commands away.
- mp_input_check_interrupt() now prints a message if it returns
true. This is especially useful because the failures caused by
aborted stream reads can trigger error messages from other code that
was doing the read; the new message makes it more obvious what the
cause of the subsequent error messages is.
- It's now possible to again avoid making stdin non-blocking (which
caused some issues) without reintroducing extra latency. The change
will be done in a subsequent commit.
- Event sources that do not support select() should now have somewhat
lower latency in certain situations as they will be checked both
before and after select()/sleep in input reading; before the sleep
always happened first even if such sources already had queued
input. Before the key fifo was also handled in this manner (first
key triggered select, but if multiple were read then rest could be
delayed; however in most cases this didn't add latency in practice
as after central code started doing command handling it queried for
further commands with a max sleep time of 0).
- Key fifo limiting is more accurate now: it now counts actual
commands intead of keycodes, and all queued keys are read
immediately from input devices so they can be counted correctly.
- Since keypresses are now interpreted immediately, commands which
change keybindings will no longer affect following keypresses that
have already been read before the command is executed. This should
not be an issue in practice with current keybinding behavior.
After commit 39e373aa8d ("options: allocate dynamic options with
talloc") dynamically allocated options must be allocated with talloc.
Code implementing -use-filename-title still set opts->vo_wintitle to a
value from strdup(), triggering an abort when the option was freed.
Fix.
