va-api support

Hi all!
How is the inclusion of va-api into the master branch mplayer?
--

-- 
Best Regards,
Igor Gnatenko

Patch for build failure with clang, lvvm, etc. on Mac OSX > 10.6

Submitted this via Bugzilla but not sure if that's the right place anymore:
http://bugzilla.mplayerhq.hu/show_bug.cgi?id=2134#c0

Darwin-specific changes to fix compilation on current Mac OS X/Xcode/clang

It is not possible to build Mplayer on Mac OS X > 10.6 due to a few
errors in the build system.  The following changes (all can be
implemented in configure for the darwin/x86_64 target) allow mplayer
to build properly.

1. using -DPIC with YASM to allow ffmpeg to compile properly
2. Using -Wl,-pie to fix linking since -pie -fpie is incorrect under
Darwin's clang
3. --mdynamic-no-pic breaks compilation due to security features in
newer versions of Mac OS X

Clang does support PIC but the configure check breaks due to the
inclusion of -fpie -pie so I added a separate check for clang and
darwin to include the right flags. After that, PIC is successfully
detected and works fine.

Attached a patch which fixes the issue and should not affect any other
platforms.

_______________________________________________
MPlayer-dev-eng mailing list
MPlayer-dev-eng <at> mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng

[PATCH] DJGPP support

Hello.
This patch allows compilation of MPlayer for MS-DOS using DJGPP dev 
environment. It applies to latest SVN rev 35946, and is based on one 
made by Khusraw of bttr-software.de forum, who ported SVN rev 34661 
(available at http://omploader.org/vY3A4Mg). Cross-compilation is made 
by adding  --target=i386-DJGPP to configure's parameters.

In order to play sounds, it needs a special version of the WSS library, 
that can be found at http://rayer.g6.cz/download/wss.zip (plus the 
relevant --extra-cflags and --extra-ldflags so configure can detect it).

A patch also needs to be applied to FFmpeg as well, see 
https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2013-March/140219.html

Regards,
Fabrizio

_______________________________________________
MPlayer-dev-eng mailing list
MPlayer-dev-eng <at> mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng

[PATCH] Add support for rotating the video via OpenGL.

---
 Changelog             |    2 ++
 DOCS/man/en/mplayer.1 |    7 +++++++
 cfg-mplayer.h         |    1 +
 libvo/aspect.c        |   30 ++++++++++++++++++++++++++----
 libvo/video_out.c     |    1 +
 libvo/video_out.h     |    8 ++++++++
 libvo/vo_gl.c         |   48 +++++++++++++++++++++++++++++++-----------------
 7 files changed, 76 insertions(+), 21 deletions(-)

diff --git a/Changelog b/Changelog
index 1110ace..953edd8 100644
--- a/Changelog
+++ b/Changelog
 <at>  <at>  -9,6 +9,8  <at>  <at>  MPlayer
     * support for XYZ color space in -vo gl
     * -vo gl now supports OSD (not EOSD though) with GLES backend.
     * GLES backend now uses GLES v2 with YUV support via shaders
+    * -vo gl supports rotated display without needing video filters via
+      -rotate command-line option.
     * -vo gl now has an OSX/Cocoa backend, so it should be a better
       alternative to -vo corevideo now.
     * -vo gl2 renamed to -vo gl_tiled to stop people from assuming it is
diff --git a/DOCS/man/en/mplayer.1 b/DOCS/man/en/mplayer.1
index 461be5f..4da08a0 100644
--- a/DOCS/man/en/mplayer.1
+++ b/DOCS/man/en/mplayer.1
 <at>  <at>  -3628,6 +3628,13  <at>  <at>  E.g.\& \-panscanrange \-3 allows a zoom factor of up to 4.
 This feature is experimental.
 .

Bugreport/Patch: x11 video backend has wrong geometry assumptions

I was bitten by a bug while doing some X window management.
From my program:

static void handle_maprequest(XEvent *ev)
{
        ...

        /* For mplayer, these two lines must be swapped
         * because it ignores any events up to the first
         * MapNotify.
         */
        XMoveResizeWindow(dpy, w, p->x, p->y, p->w, p->h);
        XMapWindow(dpy, w);
}

static void handle_configurerequest(XEvent *ev)
{
        ...

        /* This does NOT cause a ConfigureNotify event if we already
         * did a handle_maprequest() because the geometry doesn't change.
         */
        XMoveResizeWindow(dpy, w, p->x, p->y, p->w, p->h);
}

Any events preceding the MapNotify are simply ignored by mplayer. In the
situation above, as long as the geometry doesn't change after the first
map, mplayer won't receive any further ConfigureNotify Events from the X
server and thus output videos under wrong geometry assumptions.

Coverity again...

Hello,
I just put a new scan on Coverity, you are very welcome to look through
and send patches or if simple enough commit fixes!
Anyone who is a developer or otherwise willing to prove trustworthiness
can get access, please ask me.
I'm afraid I have too little time to analyze all in a reasonable time.
(note that if you are not familiar with the tool I'd advise sending
patches for any fixes unless truly trivial because I have seen all
too often people - possibly including myself  - trusting it too
much and end up breaking perfectly fine code...)

Reimar

[PATCH] Set default Blu-ray device

Submitting a local patch from our OpenBSD ports tree to set
a default Blu-ray device.

Index: configure
===================================================================
--- configure	(revision 36233)
+++ configure	(working copy)
 <at>  <at>  -5853,7 +5853,7  <at>  <at> 
 fi #if os2

 
-# set default CD/DVD devices
+# set default CD/DVD/Blu-ray devices
 if win32 || os2 ; then
   default_cdrom_device="D:"
 elif darwin ; then
 <at>  <at>  -5876,10 +5876,13  <at>  <at> 

 if win32 || os2 || dragonfly || freebsd || openbsd || sunos || amigaos ; then
   default_dvd_device=$default_cdrom_device
+  default_bluray_device=$default_cdrom_device
 elif darwin ; then
   default_dvd_device="/dev/rdiskN"
+  default_bluray_device="/dev/rdiskN"
 else
   default_dvd_device="/dev/dvd"
+  default_bluray_device="/dev/dvd"
 fi

 

[PATCH] Fix MPlayer build under mingw32 withoud pthreads with recent FFmpeg

Attached patch fixes building MPlayer with recent FFmpeg using mingw32
without pthreads.

Without this patch building stops at compiling
ffmpeg/libavutil/atomic.c with error:
"Threading is enabled, but there is no implementation of atomic
operations available"

This "#error" is triggered inside atomic.c when HAVE_THREADS is
enabled (since w32threads is available) and HAVE_ATOMICS_NATIVE
undefined
(since no such tests in configure)

Patch adds related tests to MPlayer's configure script (code got from
FFmpg's configure script)

I hope this patch will be helpful for somebody.

--

-- 
Vladimir Voroshilov     mailto:voroshil <at> gmail.com
Jabber: voroshil <at> gmail.com
ICQ: 95587719

_______________________________________________
MPlayer-dev-eng mailing list
MPlayer-dev-eng <at> mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng

[PATCH] ao_jack: add "connect" suboption

Hi,

here is a small patch to add a "(no)connect" option to the jack audio 
output module. The (unchanged) default behavior of the module is to 
limit the number of channels to the number of output ports found on the 
matching jack client and create one-to-one connections. If you want to 
get all available audio channels, you can now use "-ao jack:noconnect" 
and manually create whatever connections you desire.

Cheers,
Markus

_______________________________________________
MPlayer-dev-eng mailing list
MPlayer-dev-eng <at> mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng

buffer overrun in mp_input_parse_config

Hi,

A few people have been running with the GCC stack fence diff I came up
with, which puts a fence between each buffer (rather than the last one
as stack protector does).

Mplayer has been crashing since due to a buffer overrun in
mp_input_parse_config() which always does buffer[-1] = '\0' at the
very end.  The following fixes it and I think is what was intended.

Cheers,
Martynas.

_______________________________________________
MPlayer-dev-eng mailing list
MPlayer-dev-eng <at> mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng

[PATCH] input: add an option to set the default pausing mode.

---
 DOCS/man/en/mplayer.1 |   20 ++++++++++++++++++++
 cfg-mplayer.h         |    1 +
 input/input.c         |    4 +++-
 input/input.h         |    2 ++
 4 files changed, 26 insertions(+), 1 deletion(-)

diff --git a/DOCS/man/en/mplayer.1 b/DOCS/man/en/mplayer.1
index 524b4dd..6916ba9 100644
--- a/DOCS/man/en/mplayer.1
+++ b/DOCS/man/en/mplayer.1
 <at>  <at>  -1246,6 +1246,26  <at>  <at>  Useless with modern Linux kernels configured for desktop use as they already
 wake up the process with similar accuracy when using normal timed sleep.
 .
 .TP
+.B \-pausing <0\-3> (MPlayer only)
+Specifies the default pausing behaviour of commands, i.e. whether MPlayer
+will continue playback or stay paused after the command has finished.
+See DOCS/tech/slave.txt for further details.
+.PD 0
+.RSs
+.IPs 0
+resume
+.IPs 1
+pause (pausing)
+.IPs 2
+keep the paused / playing status (pausing_keep)
+.IPs 3
+toggle the paused / playing status (pausing_toggle)
+.IPs 4