"End of file" was printed to the terminal instead of "Quit" when exiting
with the "quit" slave command (closing the window and such). Note that
it will still print EOF when it exists because the end of the playlist
is reached.
Do some other (not strictly related) simplifications.
This was supposed to be fixed in f897138, but there's another corner
case. Basically, set_osd_function() reset the OSD time, which is not
nice at all and breaks the logic of letting OSD elements disappear when
they're not wanted anymore. Fix this by adding a separate timer for
this.
Additionally, make sure the OSD bar is _really_ always updated when
visible. Also, redraw the OSD only if the OSD bar actually changes to
prevent redrawing too often (every vo_osd_changed() will flag that the
OSD should be redrawn, even if nothing changes).
Increase robustness against out of bound chapter numbers. Normally
these functions expect that the callers sanitize the chapter number.
This went wrong at least in add_seek_osd_messages() (which displayed
a chapter "-1" when chapters were not available). Make these functions
a bit friendler and add some reasonable checks and fallbacks, which
fixes the mentioned chapter seeking case as well.
This affects the "show_progress" command, by defualt on the 'P' key.
If there are complaints, I'll probably remove it again. (It looks
relatively annoying, but it also valueable information... sort of.)
Seeks can be performed with OSD bar invisible (e.g. "osd-msg seek ..."
command), and then an already visible bar won't be updated. But the bar
will stick around until the OSD text is hidden. This is confusing, so
change it that the bar is updated. (Making the bar disappear on such
seeks would require much more changes, so we're lazy and go with this
commit.)
The seek bar appeared to be "stuck" to the start of the current chapter.
This is a regression from 630a2b1. This commit assumed that hrseek_pts
would always contain the hrseek target time (when hrseek_active==true).
But this is not always the case: when playing timeline stuff (e.g.
ordered chapters), hrseek framedropping is abused to handle an obscure
corner case, and then hrseek_pts contains something completely unrelated
to the current playback time. See the added comment in mplayer.c and
commit c1232c9.
Fix this by trying something else to get a correct time "during"
hr-seeks. mpctx->restart_playback looks ideal, because it's set while
audio is being synced / audio buffers being filled, so we know that the
audio time is probably bogus while it is set. Let's hope this is
correct.
Also move the lang field into the general stream header. (SH_COMMON is
an old hack to "share" code between audio/video/sub headers.)
There should be no functional changes, other than not printing stream
info in verbose mode or with slave mode. (The frontend already prints
stream info, and this is just a leftover when individual demuxers did
this, and slave mode remains broken.)
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.
Simplify --no-config and make it a normal flag option, and doesn't take
an argument anymore. You can get the same behavior by using --no-config
and then --include to explicitly load a certain config file.
Make --no-config work for input.conf as well. Make it so that
--input:conf=file still works in this case. As a technically unrelated
change, the file argument now works as one would expect, instead of
making it relatively to "~/.mpv/". This makes for simpler code and
easier to understand option semantics. We can also print better error
messages.
Doesn't have much of a purpose for normal playback. You can get
milliseconds display with --osd-fractions. It's also possible to build
a custom status line with --status-msg.
This gives more space on the status line and, in my opinion, is a bit
less annoying.
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}"
This fixes a problem that happened with syncplay.pl [1] when ad_mpg123
was in use, and get_current_time() returning a bogus time position.
This only happens during seeking; the reported time is correct after the
seek is done.
The audio PTS as returned by playing_audio_pts() is simply bogus during
hr-seek. With ad_ffmpeg, it was actually set to MP_NOPTS_VALUE during
seeking, so get_current_time() did a fallback to the video PTS. However,
ad_mpg123 is different and explicitly decodes some audio when resetting
on seek (reasons why it does this unknown and uninvestigated; apparently
it's to reinit libmpg123). As a result, the audio PTS was set to the
start position of the seek (or something similar), which could be very
different from the seek target time.
This confused syncplay. It got the bogus time because it spams the
player with read commands to the "time-pos" property, so this corner
case was hit.
Fix this by making get_current_time() return the seek target time if
hr-seek is active. This should make behavior the same as before commit
3f949cf "mplayer: prefer audio PTS over video PTS for status line".
[1] http://syncplay.pl
When doing a framestep while there is no more video, nothing happened,
and audio continued to play. When advancing to the next file, the player
was paused. Fix it so that it always pauses (except on very low frame
rate video, which is yet another corner case).
We also change the meaning of framestepping a bit: in audio only mode,
framstepping unpauses for a single playloop iteration. This is probably
not useful at all, but makes the code a bit more simpler/uniform.
Just like the previous commit, this matters most for audio files with
cover art, for which this special case is the normal case.
mpctx->delay is used to control audio/video sync. If more audio than
video has been played, it grows larger, meaning A/V desync is happening.
This logic is a bit broken when video has ended, and audio is still
playing. In that case, it tries to read additional video frames from the
video decoder (because even if you don't feed new packets to the
decoder, it could still return delayed frames). For that, the code to
determine whether frames should be dropped is invoked
(check_framedrop()). This function detects that video is behind audio (mpctx-
>delay growing big),
and attempts to issue a framedrop.
Reset mpctx->delay if there's no more video.
This fixes the the frame drop display "counting up" on each playloop
iteration when playing audio files with cover art. These files are
basically audio+video files with a single video frame. When playing
these files the the corner case of having run out of video while audio
is still playing is the normal case.
Also reset mpctx->last_av_difference. This is not updated anymore if
video ends (since update_avsync() sets it, but it's not called if
video_left is false). This removes the "stuck" A/V sync value when video
ends. With audio files containing cover art we would display a
meaningless value over the duration of the whole file otherwise.
Explicitly advancing the playlist with input commands ("playlist_next")
didn't jump back to the first file, if the current file was the last on
the playlist and looping was enabled.
Fix this and make the behavior with explicit input and playback EOF the
same.
Also add a minor feature: if looping is enabled, and the current file is
the first on the playlist, going back one entry jumps to the last
playlist entry (without changing loop count).
Fixes#22.
Should be dead code. Stream selection is handled either during
demuxer initialization, or via DEMUXER_CTRL_SWITCH_*.
(If there were actually situations where this code did something, it
was probably broken anyway.)
Move things that are used by vo_xv only into vo_xv, same for vo_x11.
Rename some functions exported by x11_common, like vo_init to
vo_x11_common. Make functions not used outsode of x11_common.c private
to that file. Eliminate all global variables defined by x11_common
(except error handler and colormap stuff).
There shouldn't be any functional changes, and only code is moved
around. There are some minor simplifications in the X11 init code, as
we completely remove the ability to initialize X11 and X11+VO
separately (see commit b4d9647 "mplayer: do not create X11 state in player frontend"),
and the respective functions are conflated into vo_x11_init() and
vo_x11_uninit().
If we detect Libav, always use the old builtin vobsub decoder (in
spudec.c). Note that we do not want to use it for newer ffmpeg, as
spudec.c can't handle the vobsub packets as generated by the .idx
demuxer, and we want to get rid of spudec.c in general anyway.
Drop queued frames on seek. Reset the internal state of some filters
that seem to need it as well: at least vf_divtc still produced some
frames using the previous PTS.
This fixes weird behavior with some filters on seeking. In particular,
this could lead to A/V desync or apparent lockups due to the PTS of
filtered frames being too far away from audio PTS.
This commit does only the minimally required work to fix these PTS
related issues. Some filters have state dependent on previously filtered
frames, and these are not automatically reset with this commit (even
vf_divtc and vf_softpulldown reset the PTS info only). Filters that
actually require a full reset can implement VFCTRL_SEEK_RESET.
Format changes within a file can e.g. happen in MPEG-TS streams. This
fix also fixes encoding of such files, because ao_lavc is not capable of
reconfiguring the audio stream.
VFCAP_TIMER disables any additional waiting done by mpv in the
playloop. Remove VFCAP_TIMER, but re-use the idea for vo_image and
vo_lavc.
This means --untimed doesn't have to be passed when using --vo=image.
Change the entire filter API to use reference counted images instead
of vf_get_image().
Remove filter "direct rendering". This was useful for vf_expand and (in
rare cases) vf_sub: DR allowed these filters to pass a cropped image to
the filters before them. Then, on filtering, the image was "uncropped",
so that black bars could be added around the image without copying. This
means that in some cases, vf_expand will be slower (-vf gradfun,expand
for example).
Note that another form of DR used for in-place filters has been replaced
by simpler logic. Instead of trying to do DR, filters can check if the
image is writeable (with mp_image_is_writeable()), and do true in-place
if that's the case. This affects filters like vf_gradfun and vf_sub.
Everything has to support strides now. If something doesn't, making a
copy of the image data is required.
Ensure that even if a seek is inaccurate it will not show video from
outside the defined timeline. Previously, seeking to the beginning of
a segment could show frames from before the start of the segment if
the seek was done in inaccurate mode and the demuxer seeked to an
earlier position. Now hr-seek machinery is used to skip at least the
frames that should not be part of playback timeline at all.
Now external subtitles essentially use the playback time, instead of
the segment time.
This is more useful when using external subtitles with mkv ordered
chapters. The previous behavior is not necessarily incorrect, and e.g.
makes it easier to use subtitles directly extracted from ordered
chapters segments. But we consider the new behavior more useful.
Also see commit 06e3dc8.
This is simpler and more useful. We could add a new switch for the old
functionality, but that would probably be more confusing than helpful.
When passing only a single file to the command line, this commit
shouldn't change behavior.
(Classic mplayer provided both features by duplicating the loop
functionality in the "playtree".)
When the last frame is displayed, and a frame step command is issued,
playback ands and advances to the next file. But before this commit,
the next file was played unpause. Fix this, and make sure pause is
kept.
This is better than having just the operating system type decide the
wakeup period, as e.g. when compiling for Win32/cygwin, a wakeup period
of 0.5 would work perfectly fine.
Instead, the default wakeup period is now only decided by availability
of a working select() system call (which is the case on cygwin but not
mingw and MSVC) AND a vo that can provide an event file descriptor or a
similar hack (vo_corevideo). vos that cannot do either need polling for
event handling and now can set the wakeup period to 0.02 in the vo code.
Add `mp_find_config_file` to search different known paths and use that in
ass_mp to look for the fontconfig configuration file.
Some incidental changes spawned by this feature where:
* Buffer allocation for the strings containing the paths is now performed
with talloc. All of the allocations are done on a NULL context, but it still
improves readability of the code.
* Move the OSX function for lookup inside of a bundle: this code path was
currently not used by the bundle generated with `make osxbundle`. The plan
is to use it again in a future commit to get a fontconfig config file.
Keep the currently displayed subtitles even when the user cycles through
subtitle tracks, and the subtitle is decoded by libavcodec (such as
vobsubs). Do this by not clearing the subtitles on reset(). reset() is
also called on seek, so check the start PTS whether the subtitle should
really be displayed (there's already an end PTS). Note that sd_ass does
essentially something similar.
The existing code has checks for whether the PTS reported by the demuxer
is invalid (MP_NOPTS_VALUE). I don't know under what circumstances this
can happens, so fall back to the old behavior if the PTS is invalid.
This slightly improves display of the current playback time in files
with sparse video packets (like video tracks containing a slow MJPG
slideshows as in [1]), or audio files with cover art image attachments.
While the video PTS is always "stuck" at the last frame displayed or
the last seek, audio is usually continuous. Given sane samplerates and
working audio drivers (to query how much of the current audio buffer has
been played), the audio PTS should always be more reliable.
[1] http://www.podtrac.com/pts/redirect.mp3/traffic.libsyn.com/rtpodcast/Rooster_Teeth_Podcast_191.m4a
ffmpeg pretends that image attachments (such as contained in ID3v2
metadata) are video streams. It injects the attached pictures as packets
into the packet stream received with av_read_frame().
Add the --audio-display option to allow configuring whether attached
pictures should be displayed. The default behavior doesn't change
(images are displayed).
Identify video streams, that are actually image attachments, with "[P]"
in the terminal output.
Modify the default stream selection such that real video streams are
preferred over attached pictures. (This is just for robustness; I do not
know of any samples where images are added before actual video streams
and could lead to bad default stream selection with the old code.)
This caused errors like:
core/mplayer.c:4308:5: error: implicit declaration of function 'pthread_win32_thread_detach_np' [-Werror=implicit-function-declaration]
It turns out a pthread.h include was missing. It's not clear why this
used to work (or rather, why it happens only sometimes). Possibly some
libraries or system headers recursively include pthread.h under certain
circumstances or configurations.
Fix missing quoting in configure, which led to broken terminal output.
Closes#6.
ffmpeg recently added a demuxer that can read vobsubs (pairs of .sub and
.idx files). Get rid of the internal vobsub reader, and use the ffmpeg
demuxer instead.
Sneak in an unrelated manpage change (autosub default).
This affects streams loaded with -subfile and -audiofile. They could get
out of sync when they were deselected, and the main file was seeked. Add
code to seek external files when they are selected (see
init_demux_stream()).
Use avformat_seek_file() under certain circumstances. Both av_seek_frame()
("old" API) and avformat_seek_file() ("new" API) seem to be broken with
some formats. At least the vobsub demuxer doesn't implement the old API
(and the old API doesn't fallback to the new API), while the fallback
from new API to old API gives bad results. For example, seeking forward
with small step sizes seems to fail with the new API (tested with
Matroska by trying to seek 1 second forward relative to priv->last_pts).
Since only subtitle demuxers implement the new API anyway, checking
whether iformat->read_seek2 is set to test whether the old API is not
supported gives best results. This is a hack at best, but makes things
work.
Remove backwards seeking on seek failure. This was annoying, and only
was there to compensate for obscure corner cases (see 1ad332). In
particular, files with completely broken seeking that used to skip back
to the start on every seek request may now terminate playback.
Do this only if demux_lavf is used. Using demux_mpg and the ffmpeg DVD
subtitle decoder doesn't work. The problem is probably that demux_mpg
doesn't join split sub packets, while demux_lavf does. The internal
DVD sub decoder (spudec.c) can, while ffmpeg's dvdsub can't. I do not
know whether this is the actual problem.
If DVD playback is used, create "fake" vobsub-style text extradata
(like .idx files) to pass resolution and palette information to the
ffmpeg decoder. We could use the "palette" AVOpt and avcodec_set_dimensions()
instead, but it's actually simpler this way. Note that the decoder
doesn't parse any other fields. Also note that DVD playback still uses
demux_mpg by default, so this code is inactive unless -demuxer lavf is
specified. This is mainly preparation for the case when we manage to get
rid of demux_mpg for DVD playback.
When the cache fill status goes below a certain threshold, automatically
pause the player. When the cache is filled again, unpause again.
This is intended to help with streaming from http. It's better to pause
a while, rather than exposing extremely crappy behavior when packet
reads during decoding block the entire player.
In theory, we should try to increase the cache if underruns happen too
often. Unfortunately, changing the cache implementation would be very
hard, because it's insane code (forks, uses shared memory and "volatile"
etc.). So for now, this just reduces the frequency of the stuttering if
the network is absolutely too slow to play the stream in realtime.
This commit is separate from the previous one to separate our own
changes from changes merged from mplayer2 (as far as that was possible).
Make it easier for stream implementations to request being cached. Set
a default cache size in stream.c, and remove them from various stream
implementations. Only MS streaming support sets a meaningful cache size.
Make querying cache size saner. This reduces the amount of #ifdefs
needed.
Code enabling the cache by default for network streams did that by
modifying the value of the "cache" option. This wasn't sane, as
multiple streams may be created and all share the same options. Change
the code to not modify options but store data in the stream instance
instead.
Conflicts:
core/mplayer.c
demux/demux.c
stream/cache2.c
stream/network.c
stream/network.h
stream/pnm.c
stream/stream.c
stream/stream_rtp.c
Merged from mplayer2 commit e26070. Note that this doesn't solve any
actual bug, as the playlist crashing bug has been fixed before.
Since the global cache size option value is not overwritten anymore, the
option doesn't need to be restored on end of playback (M_OPT_LOCAL).
wm4
Rudolf Polzer
Uoti Urpala
Stefano Pigozzi