media-video/mpv: backport build, memleak, AV sync fixes for 0.18.0

We'll keep 0.18.0 longer than usual as 0.18.1 changed how volume
levels work in a partially incompatible way.
This causes problems at least in smplayer, see Gentoo bug 588584.

Package-Manager: portage-2.3.0

Signed-off-by: Patrice Clement <monsieurp@gentoo.org>

4 files changed, 92 insertions, 1 deletions

diff --git a/media-video/mpv/files/0.18.0/mpv-0.18.0-fix-doc-build.patch b/media-video/mpv/files/0.18.0/mpv-0.18.0-fix-doc-build.patch
new file mode 100644
index 000000000000..26c8f72d4dae
--- /dev/null
+++ b/media-video/mpv/files/0.18.0/mpv-0.18.0-fix-doc-build.patch
@@ -0,0 +1,23 @@
+commit 4a4a9f330281ad11eb39a013bf7308063767bab8
+Author: Martin Herkt <lachs0r@srsfckn.biz>
+Date:   Fri Jul 15 12:57:12 2016 +0200
+
+man: fix PDF build error
+
+ReportLab really doesn’t like breaking inline literals, so insert an
+explicit line break.
+
+Fixes #3338
+
+diff --git a/DOCS/man/options.rst b/DOCS/man/options.rst
+index 9a251ae..74d17a6 100644
+--- a/DOCS/man/options.rst
++++ b/DOCS/man/options.rst
+@@ -588,6 +588,7 @@ Video
+     :videotoolbox: requires ``--vo=opengl`` (OS X 10.8 and up only)
+     :videotoolbox-copy: copies video back into system RAM (OS X 10.8 and up only)
+     :dxva2: requires ``--vo=opengl:backend=angle`` or
++
+         ``--vo=opengl:backend=dxinterop`` (Windows only)
+     :dxva2-copy: copies video back to system RAM (Windows only)
+     :d3d11va: requires ``--vo=opengl:backend=angle`` (Windows only)
diff --git a/media-video/mpv/files/0.18.0/mpv-0.18.0-fix-fbo-resize-memleak.patch b/media-video/mpv/files/0.18.0/mpv-0.18.0-fix-fbo-resize-memleak.patch
new file mode 100644
index 000000000000..9407f15283d5
--- /dev/null
+++ b/media-video/mpv/files/0.18.0/mpv-0.18.0-fix-fbo-resize-memleak.patch
@@ -0,0 +1,27 @@
+commit 3abf9c9204e2fcbc1910deb102efab4ab9d8c149
+Author: Niklas Haas <git@nand.wakku.to>
+Date:   Wed Jun 8 17:32:40 2016 +0200
+
+vo_opengl: don't constantly resize the output FBO
+
+Commit 883d3114 seems to have (accidentally?) dropped the FBOTEX_FUZZY
+from the output_fbo resize, which means that current master will keep
+resizing and resizing the FBO as you change the window size, introducing
+severe memory leaking after a while. (Not sure why that would cause
+memory leaks, but I blame nvidia)
+
+Either way, it's bad for performance too, so it's worth fixing.
+
+diff --git a/video/out/opengl/video.c b/video/out/opengl/video.c
+index bd1eb89..6c7646b 100644
+--- a/video/out/opengl/video.c
++++ b/video/out/opengl/video.c
+@@ -2791,7 +2791,7 @@ void gl_video_render_frame(struct gl_video *p, struct vo_frame *frame, int fbo)
+                 {
+                     fbotex_change(&p->output_fbo, p->gl, p->log,
+                                   p->vp_w, abs(p->vp_h),
+-                                  p->opts.fbo_format, 0);
++                                  p->opts.fbo_format, FBOTEX_FUZZY);
+                     dest_fbo = p->output_fbo.fbo;
+                     p->output_fbo_valid = true;
+                 }
diff --git a/media-video/mpv/files/0.18.0/mpv-0.18.0-fix-height-alignment-on-xv.patch b/media-video/mpv/files/0.18.0/mpv-0.18.0-fix-height-alignment-on-xv.patch
index 550b493b40f0..5033157251fb 100644
--- a/media-video/mpv/files/0.18.0/mpv-0.18.0-fix-height-alignment-on-xv.patch
+++ b/media-video/mpv/files/0.18.0/mpv-0.18.0-fix-height-alignment-on-xv.patch
@@ -11,7 +11,6 @@ makes sense, so it can't certainly be considered server misbehavior.
 Do 2 things against this: allow if the server returns a larger image (we
 just crop it then), and also allocate a properly aligned image in the
 first place.
----
 
 diff --git a/video/out/vo_xv.c b/video/out/vo_xv.c
 index 1e7ae7c..a5a4728 100644
diff --git a/media-video/mpv/files/0.18.0/mpv-0.18.0-fix-initial-av-sync.patch b/media-video/mpv/files/0.18.0/mpv-0.18.0-fix-initial-av-sync.patch
new file mode 100644
index 000000000000..c2cacc3bff7a
--- /dev/null
+++ b/media-video/mpv/files/0.18.0/mpv-0.18.0-fix-initial-av-sync.patch
@@ -0,0 +1,42 @@
+commit 614efea3e67a435f3330820c3dc8b402535641e8
+Author: wm4 <wm4@nowhere>
+Date:   Fri Jul 1 15:51:34 2016 +0200
+
+ad_lavc: work around braindead ffmpeg behavior
+
+The libavcodec wmapro decoder will skip some bytes at the start of the
+first packet and return each time. It will not return any audio data in
+this state.
+
+Our own code as well as libavcodec's new API handling
+(avcodec_send_packet() etc.) discard the PTS on the first return, which
+means the PTS is never known for the first packet. This results in a
+"Failed audio resync." message.
+
+Fixy it by remember the PTS in next_pts. This field is used only if the
+decoder outputs no PTS, and is updated after each frame - and thus
+should be safe to set.
+
+(Possibly this should be fixed in libavcodec new API handling by not
+setting the PTS to NOPTS as long as no real data has been output. It
+could even interpolate the PTS if the timebase is known.)
+
+Fixes the failure message seen in #3297.
+
+diff --git a/audio/decode/ad_lavc.c b/audio/decode/ad_lavc.c
+index f48993f..0316f6b 100644
+--- a/audio/decode/ad_lavc.c
++++ b/audio/decode/ad_lavc.c
+@@ -186,6 +186,12 @@ static int decode_packet(struct dec_audio *da, struct demux_packet *mpkt,
+     struct priv *priv = da->priv;
+     AVCodecContext *avctx = priv->avctx;
+
++    // If the decoder discards the timestamp for some reason, we use the
++    // interpolated PTS. Initialize it so that it works for the initial
++    // packet as well.
++    if (mpkt && priv->next_pts == MP_NOPTS_VALUE)
++        priv->next_pts = mpkt->pts;
++
+     int in_len = mpkt ? mpkt->len : 0;
+
+     AVPacket pkt;