Allows using of directrendering for hw acceleration, with fallbacl to directbuffer.
No more black frames. No more flickering.
patch by Christoph Egger, approved by al3x
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@14022 b3059339-0415-0410-9bf9-f77b7e298cf2
Xlib funtions allocate memory that should be freed appropriately
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@13954 b3059339-0415-0410-9bf9-f77b7e298cf2
Based on a patch by Sebastian Hegler <s_hegler at gmx dot de>.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@13788 b3059339-0415-0410-9bf9-f77b7e298cf2
It's now possible to compile libvo without pnm and/or md5sum support.
Default is enable.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@13745 b3059339-0415-0410-9bf9-f77b7e298cf2
a simple 32 bits protected mode interface to some VESA functions. This
protected mode interface is interesting because it's quicker than the
raw int 10h interface.
Unfortunatly, begining with VBE 3.0, the 0x4f0a function is optional,
and some video cards don't implement it (3dfx, intel 845/855/865...).
This protected mode interface is then only used in vbeSetWindow and
vbeSetDisplayStart :
- vbeSetWindow already implement an alternative methode if protected
mode interface is not available.
- vbeSetDisplayStart also contain an alternative implementation, but
this one is disabled with a #if 0. I don't exactly know why because
it works well !
So currently, cards which don't have the 0x4f0a function are not
supported. This patch correct this.
- vbeGetProtModeInfo failure is not fatal.
- vbeSetDisplayStart has it's alternative implementation reenabled.
it's used only with cards which don't have the 0x4f0a function
so this won't make any difference for cards which were already
working.
This patch also make the failure of vbeGetModeInfo not fatal. The
VBE 3.0 standard state that GetModeInfo can fail with some mode
which are listed as supported if the mode can't be used in the
current situation (not enough video memory for example). So a
failure of vbeGetModeInfo don't mean that other modes won't work
and should really not be fatal.
patch by Aurelien Jacobs <aurel@gnuage.org>
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@13569 b3059339-0415-0410-9bf9-f77b7e298cf2
and vo_md5sum. If one tries to use the old video output drivers, a message
is printed to direct them to the new drivers.
Manual page is updated (or is this called downdated? :-) ).
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@13508 b3059339-0415-0410-9bf9-f77b7e298cf2
and writes a list of those sums to an, optionally specified, output file.
It does not rely on external programs to be installed. The MD5 sum code is
borrowed from the uCIFS library, written by Christopher R. Hertel in 2004
and released under the LGPL license.
Note: This driver is not yet activated and will not be compiled and linked
to libvo. A separate patch will take care of that. This is just for adding
the files to the repository.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@13396 b3059339-0415-0410-9bf9-f77b7e298cf2
pixmaps and graymaps in both raw and ASCII mode. Besides PPM and PGM, it
can also output PGMYUV files which are PGM files with the U and V plane
appended to the bottom of the Y image (bottom left and bottom right). All
files can be written to the current directory, to a specified output directory
or to multiple subdirectories if the filesystem can't handle the amount of
files in one directory anymore.
Note: This driver is not yet activated and will not be compiled and linked
to libvo. A separate patch will take care of that. This is just for adding
the file to the repository.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@13395 b3059339-0415-0410-9bf9-f77b7e298cf2
the upper left corner like in vo fbdev[2].
Reason: vo cvidix does not know the screen resolution unlike you specify
it with screen[w/h], resulting in the video being displayed on a random
position.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@13356 b3059339-0415-0410-9bf9-f77b7e298cf2
implements
SSA alignment styles; note that alignment for SSA files is not actually
supported, but for SAMI files (which use the same alignment codes) it
is.
patch by Salvatore Falco <sfalco at studenti.ing.uniroma1.it>
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@13344 b3059339-0415-0410-9bf9-f77b7e298cf2
* More error checking. If malloc or strdup fails, print message and exit.
* Free malloc'd memory when uninit is called.
* Moved default of jpeg_outdir to preinit, so it is always malloc'd and can
easily be freed at uninit.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@13317 b3059339-0415-0410-9bf9-f77b7e298cf2
code, before I moved both and created a function for that).
Made code clearer by moving ++variable out of a function call.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@13301 b3059339-0415-0410-9bf9-f77b7e298cf2
easily be re-used by other video output drivers, without having inapproriate
names.
To make live easier for the translators, I have made the same changes to
the German and Spanish translations (those who already picked up on the
MSGTR_VO_* messages).
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@13285 b3059339-0415-0410-9bf9-f77b7e298cf2
tried to re-use as much code as possible, to reduce the size of the patch.
All duplicate code is removed, resulting in my first patch that actually
decreases the size of the binary by about 700 bytes :-)
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@13284 b3059339-0415-0410-9bf9-f77b7e298cf2
Removed unused variable dst.
MPlayer now exits if it is unable to create a file for JPEG output and prints
an appropriate message, instead of going on if all is right (which is not).
Added line to authors file.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@13253 b3059339-0415-0410-9bf9-f77b7e298cf2
It's replaced by an options parser in the module itself. Instead of
mplayer -vo jpeg -jpeg options one now has to use mplayer -vo jpeg:options.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@13248 b3059339-0415-0410-9bf9-f77b7e298cf2
I finally got rid of the horrible one-space indentation. Changed it to four
spaces. Also changed all function calls, assignments, et cetera, to conform
to a certain 'standard'. Removed all trailing whitespace. No more tabs (width
can be different from editor to editor), it's all spaces now. Next
semi-cosmetics stop will be doxygen comments.
Tested: It compiles to exactly the same object as before. No functional
change has been made.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@13218 b3059339-0415-0410-9bf9-f77b7e298cf2
All by manyfmts suboption supported formats should display correctly now.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@13207 b3059339-0415-0410-9bf9-f77b7e298cf2
updated all man pages except chinese
also added mention of vo_quartz's rootwin to man pages where it was missing
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@13091 b3059339-0415-0410-9bf9-f77b7e298cf2
Original patch by Piotr Neuman <sikkh@wp.pl>
extended by Joey to cover all X11 code
modified by me to only do the above stated change.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@13057 b3059339-0415-0410-9bf9-f77b7e298cf2
on the CCC-Camp ICMP2 (www.icmp2.de) this weekend, some friends and
I played around with our Blinkenlights replicas and found a little
bug in your MPlayer Blinkenlights outpur driver "vo_bl". The
Blinkenlights UDP-Protocol contains the maximum grayscale value
"maxval" (e.g. 255 for 8 bit) instead of the number of grayscales
(e.g. 256 for 8 bit). Because some programs are very strict
concerning this value, we had to patch mpalyer to get it to work.
Today, I've added an output scheme "hdl" for the Haus des Lehrers in
Berlin, on which an installation with grayscales was done last
winter. Additionally, I've also added an output scheme named
"grayscale" that adapts the size of the UDP packets to the size
used with "-vf scale -zoom" that we will need for a project (a room
with over 15000 pixels at the walls and floor) next year.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@13001 b3059339-0415-0410-9bf9-f77b7e298cf2
faust3
iive
al
reimar
diego
nplourde
atmos4
ivo
aurel
alex
syrjala
rathann
joey
nicodvb
rik