Part of the code is currently under #ifdef to allow compilation with
older VDPAU library versions; that can be removed later.
Partially based on a patch by Carl Eugen Hoyos.
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.
* 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 code to reinitialize all VDPAU objects if a display preemption
condition occurs. Reinitializing them in the middle of playback will
cause video corruption at least until the next keyframe when using
hardware decoding, but decoding does seem to recover after a keyframe.
Create a single large bitmap surface for EOSD objects and pack all the
bitmap rectangles inside that. The old code created a separate bitmap
surface for every bitmap and then resized the cached surfaces when
drawing later frames. The number of surfaces could be large (at least
about 2000 for one sample subtitle script) so this was very
inefficient. The old code also used a very simple strategy for pairing
existing surfaces to new bitmaps; it could resize tiny surfaces to
hold large glyphs while using existing large surfaces to hold tiny
glyphs and as a result allocate arbitrarily much more total surface
area than was necessary.
The new code only supports using a single surface, freeing it and
allocating a larger one if necessary. It would be possible to support
multiple surfaces in case of hitting the maximum bitmap surface size,
but I'll wait to see if that is actually needed before implementing
it. NVIDIA seems to support bitmap surface sizes up to 8192x8192, so
it would take either a really pathological subtitle script rendered at
a high resolution or an implementation with lower limits before
multiple surfaces would be necessary.
The packing algorithm should successfully pack the bitmaps into a
surface of size w*h as long as the total area of the bitmaps does not
exceed 16/17 (w-max_bitmap_width)*(h-max_bitmap_height), so there
should be no totally catastrophic failure cases. The 16/17 factor
comes from approximate sorting used in the algorithm. On average
performance should be better than this minimum guaranteed level.
Add a template file that contains a single listing of various
information needed about the VDPAU interface functions, and is then
included multiple times to create required declarations and tables.
Previously some of the information needed to be duplicated for each of
those uses.
this version of the check assumes that we run on a system with apt-get
installed and configured. We should probably check that this is actually
true. Or more ideally add support for yum for fedora systems.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29227 b3059339-0415-0410-9bf9-f77b7e298cf2
This patch contains no functional changes again, only whitespace fixes
that has been misse from Part 1 have been included.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29223 b3059339-0415-0410-9bf9-f77b7e298cf2
This patch contains the OKed parts of Diego's review from 23. Apr 2009
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29222 b3059339-0415-0410-9bf9-f77b7e298cf2
This patch contains no functional changes, only whitespace fixes from
Debian.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29220 b3059339-0415-0410-9bf9-f77b7e298cf2
available memcpy variants and prints benchmark results about them.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28929 b3059339-0415-0410-9bf9-f77b7e298cf2
- Remove all tabs and trailing whitespace.
- Indent with 4 spaces.
- K&R-ify and prettyprint some parts.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28903 b3059339-0415-0410-9bf9-f77b7e298cf2
r3082 | michael | 2001-11-23 13:00:40 +0100 (Fri, 23 Nov 2001) | 2 lines
missaligned arrays, as nick requested
Reason: idiotic idea
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28890 b3059339-0415-0410-9bf9-f77b7e298cf2
We were using an inconsistent mix of the three variants and 'volatile' should
be the most correct and portable variant.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@27791 b3059339-0415-0410-9bf9-f77b7e298cf2
Neither variant is valid C99 syntax, but __asm__ is the most portable variant.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@27788 b3059339-0415-0410-9bf9-f77b7e298cf2
This is what it is called in FFmpeg and more consistent with other
names for similar conditionals. This fixes a potential compilation
failure on MinGW, as described in Bugzilla #1262.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@27493 b3059339-0415-0410-9bf9-f77b7e298cf2
with the ones from libmpdemux/aviheader.h, which is #included below.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@26612 b3059339-0415-0410-9bf9-f77b7e298cf2
TOOLS/movinfo.c:332: warning: '0' flag used with '%s' printf format
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@26506 b3059339-0415-0410-9bf9-f77b7e298cf2
warning: '0' flag ignored with precision and '%d' printf format
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@26481 b3059339-0415-0410-9bf9-f77b7e298cf2
need it, it should be set from configure and the reason why it was set in
the first place has been lost in the mists of time.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@26387 b3059339-0415-0410-9bf9-f77b7e298cf2
vivodump.c:213: warning: format '%08X' expects type 'unsigned int', but argument 2 has type 'long int'
vivodump.c:220: warning: format '%08X' expects type 'unsigned int', but argument 2 has type 'long int'
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@25337 b3059339-0415-0410-9bf9-f77b7e298cf2
asfinfo.c: In function 'print_wave_header':
asfinfo.c:114: warning: format '%d' expects type 'int', but argument 2 has type 'long int'
asfinfo.c:115: warning: format '%d' expects type 'int', but argument 2 has type 'long int'
asfinfo.c: In function 'print_video_header':
asfinfo.c:140: warning: format '%d' expects type 'int', but argument 2 has type 'long int'
asfinfo.c:141: warning: format '%d' expects type 'int', but argument 2 has type 'long int'
asfinfo.c:142: warning: format '%d' expects type 'int', but argument 2 has type 'long int'
asfinfo.c:145: warning: format '%d' expects type 'int', but argument 2 has type 'long int'
asfinfo.c:146: warning: format '%d' expects type 'int', but argument 2 has type 'long int'
asfinfo.c: In function 'main':
asfinfo.c:174: warning: format '%X' expects type 'unsigned int', but argument 2 has type 'long int'
asfinfo.c:220: warning: format '%d' expects type 'int', but argument 6 has type 'long unsigned int'
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@25336 b3059339-0415-0410-9bf9-f77b7e298cf2
but nevertheless has no specific arguments to work with. it will traverse
the tree from there, but obviously cannot find our externals.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@25312 b3059339-0415-0410-9bf9-f77b7e298cf2
according to svn info
.svn might be missing (i.e. after svn export)
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@25309 b3059339-0415-0410-9bf9-f77b7e298cf2
Uoti Urpala
compn
diego
siretart
reimar
michael
ivo