At least show the extra frames even if correct-pts mode is disabled.
They cannot be timed properly though; the most practical way to fix
that is to just move to correct-pts mode instead.
OSD contents such as video position and non-libass subtitles were
updated just before feeding a video frame through filters. The updates
were done at that point mainly for the benefit of vf_expand OSD
rendering functionality, which draws the OSD contents when the frame
passes through that filter. However this gave the wrong results for
VO-drawn OSD if the filter chain or VO had any delay or timestamp
manipulation: the OSD contents should reflect the most recent contents
that were _output_ after any filtering, not the last frame that was
fed _into_ the filtering machinery. This issue became more important
after vo_vdpau started buffering frames by default.
Move the OSD updates to be done just before the OSD is drawn, using
the most accurate available information. This fixes the common case
but worsens vf_expand OSD behavior (adding extra latency). A special
case could be added to fall back to the previous behavior when
vf_expand OSD is being used; however I don't consider that a high
priority at the moment especially when other problems with vf_expand
OSD would still remain.
This has little effect on libass-rendered subtitles either way,
because both vf_ass and VO libass rendering use timestamps from the
filter chain and do not rely on separate position updates.
Add a mode where libavcodec's reordered_opaque feature is used to
associate container packet timestamps with decoded frames. This should
improve behavior at least for MPEG files with interlaced h264; the
previous code does not cope well with the libavformat demuxer
producing two field packets with separate timestamps but the
libavcodec h264 decoder only producing a single output frame for those
two packets (so half the timestamps have no associated output frame).
The current libavformat mpeg demuxer seems to finally work with
interlaced h264 files and produce valid timestamps which are useful
with a mode like this.
By default MPlayer now selects between this new mode and the old one
automatically based on the number of timestamp problems they cause; by
default the new mode is used if both seem to work. The new option
-pts-association-mode can be used to force a particular mode. If
correct-pts mode is disabled this has no effect on timing.
Also remove the "EXPERIMENTAL" marker from the manpage description of
-correct-pts.
Main things added are custom frame dropping for VDPAU to work around
the display FPS limit, frame timing adjustment to avoid jitter when
video frame times keep falling near vsyncs, and use of VDPAU's timing
feature to keep one future frame queued in advance.
NVIDIA's VDPAU implementation refuses to change the displayed frame
more than once per vsync. This set a limit on how much video could be
sped up, and caused problems for nearly all videos on low-FPS video
projectors (playing 24 FPS video on a 24 FPS projector would not work
reliably as MPlayer may need to slightly speed up the video for AV
sync). This commit adds a framedrop mechanism that drops some frames
so that no more than one is sent for display per vsync. The code
tries to select the dropped frames smartly, selecting the best one to
show for each vsync. Because of the timing features needed the drop
functionality currently does not work if the correct-pts option is
disabled.
The code also adjusts frame timing slightly to avoid jitter. If you
for example play 24 FPS video content on a 72 FPS display then
normally a frame would be shown for 3 vsyncs, but if the frame times
happen to fall near vsyncs and change between just before and just
after then there could be frames alternating between 2 and 4
vsyncs. The code changes frame timing by up to one quarter vsync
interval to avoid this.
The above functionality depends on having reliable vsync timing
information available. The display refresh rate is not directly
provided by the VDPAU API. The current code uses information from the
XF86VidMode extension if available; I'm not sure how common cases
where that is inaccurate are. The refresh rate can be specified
manually if necessary.
After the changes in this commit MPlayer now always tries to keep one
frame queued for future display using VDPAU's internal timing
mechanism (however no more than 50 ms to the future). This should make
video playback somewhat more robust against timing inaccuracies caused
by system load.
Make audio uninit consistent with e.g. the demuxer uninit code and
also avoids a possible crash.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29908 b3059339-0415-0410-9bf9-f77b7e298cf2
being paused (e.g. because of a "pausing_keep_force pt_step 1").
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29898 b3059339-0415-0410-9bf9-f77b7e298cf2
and if it is unchanged re-apply -slang on stream reset.
This makes -slang work when used with menu navigation or in general
when the subtitle is not available for parts of the playback or the
subtitle stream ID changes during playback.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29897 b3059339-0415-0410-9bf9-f77b7e298cf2
This seems to leave the ts demuxer unaffected, but fixes -tsprog with
the lavf demuxer.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29846 b3059339-0415-0410-9bf9-f77b7e298cf2
decoder is used but the hardware does not support hardware MPEG audio).
Otherwise this will lead to a crash later on when the decode code tries to access
the audio filter chain.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29836 b3059339-0415-0410-9bf9-f77b7e298cf2
selecting the subtitle via -slang or -sid.
It is quite possible that removing it will cause other issues, though
I could not see any with the DVDs I had available for testing.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29827 b3059339-0415-0410-9bf9-f77b7e298cf2
Move av_log callback handling from vd_ffmpeg.c to a new file
av_log.c and install the callback immediately when starting the
program. Main functionality improvements of the new code:
- The old version only installed the callback when opening an FFmpeg
video decoder. If nothing had triggered that then av_log() messages
from other sources (libavformat, audio decoding, swscale usage)
bypassed MPlayer's output system completely. Now the callback is
always installed.
- Current av_log message severity levels are handled correctly. The
old code used MSGL_ERR for some messages that should be MSGL_V.
- Message type is now set for libavformat contexts
(MSGT_DEMUXER / MSGT_MUXER).
- The old code did "mp_msg_test(type, mp_level)" before actually
determining the type, so that it always used MSGT_FIXME. This led
to some messages being incorrectly dropped in case the user
had specified module-specific verbosity levels. The old check in
question was originally motivated by performance problems when
there were a lot of callbacks; however it's not clear whether the
part about it skipping the type determination was intentional (most
of the performance problems must have come from the way the
original code used snprintf) and in my tests current FFmpeg
libraries have not generated unreasonable amounts of callbacks
anyway.
As part of merging subtitle-in-terminal changes make
update_subtitles() only clear existing subtitles if called with the
reset argument, and not try to set new ones. Later calls should set
the needed new subtitles, and this change avoids some problems with
trying to set subtitles when mp_property_sub() in command.c gets
called from initialization code before full initialization.
This still needs some additional checking that subtitle selection via dvdnav works.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29732 b3059339-0415-0410-9bf9-f77b7e298cf2
This fixes a crash with e.g. auto-enabled subtitles and -novideo due to
command.c calling update_subtitles even without video and is a step
toward subtitle support for audio-only files.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29710 b3059339-0415-0410-9bf9-f77b7e298cf2
* vdpau: (22 commits)
VO: Prefer vo_vdpau over vo_xv again
vo_vdpau: Fix X event handling bugs
vo_vdpau: Fix memory corruption bug with MP_IMGTYPE_NUMBERED
core/VO: Allow VO drivers to add/modify frames
video_out.h: Cosmetics
VO interface: Remove obsolete draw_frame() from new interface
vo_vdpau: Support recovering from VDPAU display preemption
vo_vdpau: Support updating OSD while paused
vo_vdpau.c: Reindent control() switch statement
vo_vdpau: Allocate one large surface for EOSD content
vo_vdpau.c: cosmetics
vo_vdpau: reindent after GUI code removal
vo_vpdau: Clean up uninit logic
vo_vdpau: Make CHECK_ST macro safer
vo_vdpau: Move all remaining static/global variables to context
vo_vdpau: Move things to context struct
vo_vdpau: Make info struct const
vo_vdpau: Replace global function table with context variable
vo_vdpau: Move VDPAU interface pointers into one struct
vo_vdpau: Add template file for VDPAU functions
...
Add interfaces to allow VO drivers to add or remove frames from the
video stream and to alter timestamps. Currently this functionality
only works with in correct-pts mode. Use the new functionality in
vo_vdpau to properly support frame-adding deinterlace modes.
Frames added by the VDPAU deinterlacing code are now properly timed.
Before every second frame was always shown immediately (probably next
monitor refresh) after the previous one, even if you were watching
things in slow motion, and framestepping didn't stop at them at all.
When seeking the deinterlace algorithm is no longer fed a mix of
frames from old and new positions.
As a side effect of the changes a problem with resize events was also
fixed. Resizing calls video_to_output_surface() to render the frame at
the new resolution, but before this function also changed the list of
history frames, so resizing could give an image different from the
original one, and also corrupt next frames due to them seeing the
wrong history. Now the function has no such side effects. There are
more resize-related problems though that will be fixed in a later
commit.
The deint_mpi[] list of reserved frames is increased from 2 to 3
entries for reasons related to the above. Having 2 entries is enough
when you initially get a new frame in draw_image() because then you'll
have those two entries plus the new one for a total of 3 (the code
relied on the oldest mpi implicitly staying reserved for the duration
of the call even after usage count was decreased). However if you want
to be able to reproduce the rendering outside draw_image(), relying on
the explicitly reserved list only, then it needs to store 3 entries.
This should really be done via the NXCOMPAT PE flag, but looks like
binutils will not get support for it any time soon and not having this
security feature enabled is just ridiculous.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29683 b3059339-0415-0410-9bf9-f77b7e298cf2
current file name against full name to be added, not current file name
against new base path.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29637 b3059339-0415-0410-9bf9-f77b7e298cf2
file name strings that might come from arbitrary playlists, use PATH_MAX instead.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29636 b3059339-0415-0410-9bf9-f77b7e298cf2
dvbin.h #includes some system DVB headers that may be unavailable.
Fixes compilation with DVB disabled.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29474 b3059339-0415-0410-9bf9-f77b7e298cf2
