media-video/mpv: remove old

Package-Manager: Portage-2.3.24, Repoman-2.3.6

4 files changed, 0 insertions, 158 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
deleted file mode 100644
index 26c8f72d4dae..000000000000
--- a/media-video/mpv/files/0.18.0/mpv-0.18.0-fix-doc-build.patch
+++ /dev/null
@@ -1,23 +0,0 @@
-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
deleted file mode 100644
index 9407f15283d5..000000000000
--- a/media-video/mpv/files/0.18.0/mpv-0.18.0-fix-fbo-resize-memleak.patch
+++ /dev/null
@@ -1,27 +0,0 @@
-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
deleted file mode 100644
index 5033157251fb..000000000000
--- a/media-video/mpv/files/0.18.0/mpv-0.18.0-fix-height-alignment-on-xv.patch
+++ /dev/null
@@ -1,66 +0,0 @@
-commit 22c76e85db88a772e3360892cd3a673a89c6fc7a
-Author: wm4 <wm4@nowhere>
-Date:   Sat Jun 25 12:44:42 2016 +0200
-
-vo_xv: fix behavior with odd sizes
-
-The size check introduced in commit d941a57b did not consider that Xv
-can round up the image size to the next chroma boundary. Doing that
-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
---- a/video/out/vo_xv.c
-+++ b/video/out/vo_xv.c
-@@ -533,6 +533,8 @@ static bool allocate_xvimage(struct vo *vo, int foo)
-     struct vo_x11_state *x11 = vo->x11;
-     // align it for faster OSD rendering (draw_bmp.c swscale usage)
-     int aligned_w = FFALIGN(ctx->image_width, 32);
-+    // round up the height to next chroma boundary too
-+    int aligned_h = FFALIGN(ctx->image_height, 2);
- #if HAVE_SHM && HAVE_XEXT
-     if (x11->display_is_local && XShmQueryExtension(x11->display)) {
-         ctx->Shmem_Flag = 1;
-@@ -546,7 +548,7 @@ static bool allocate_xvimage(struct vo *vo, int foo)
-         ctx->xvimage[foo] =
-             (XvImage *) XvShmCreateImage(x11->display, ctx->xv_port,
-                                          ctx->xv_format, NULL,
--                                         aligned_w, ctx->image_height,
-+                                         aligned_w, aligned_h,
-                                          &ctx->Shminfo[foo]);
-         if (!ctx->xvimage[foo])
-             return false;
-@@ -569,7 +571,7 @@ static bool allocate_xvimage(struct vo *vo, int foo)
-         ctx->xvimage[foo] =
-             (XvImage *) XvCreateImage(x11->display, ctx->xv_port,
-                                       ctx->xv_format, NULL, aligned_w,
--                                      ctx->image_height);
-+                                      aligned_h);
-         if (!ctx->xvimage[foo])
-             return false;
-         ctx->xvimage[foo]->data = av_malloc(ctx->xvimage[foo]->data_size);
-@@ -578,16 +580,16 @@ static bool allocate_xvimage(struct vo *vo, int foo)
-         XSync(x11->display, False);
-     }
-
--    if ((ctx->xvimage[foo]->width != aligned_w) ||
--        (ctx->xvimage[foo]->height != ctx->image_height)) {
--        MP_ERR(vo, "Got XvImage with incorrect size: %ux%u (expected %ux%u)\n",
-+    if ((ctx->xvimage[foo]->width < aligned_w) ||
-+        (ctx->xvimage[foo]->height < aligned_h)) {
-+        MP_ERR(vo, "Got XvImage with too small size: %ux%u (expected %ux%u)\n",
-                ctx->xvimage[foo]->width, ctx->xvimage[foo]->height,
-                aligned_w, ctx->image_height);
-         return false;
-     }
-
-     struct mp_image img = get_xv_buffer(vo, foo);
--    img.w = aligned_w;
-+    mp_image_set_size(&img, aligned_w, aligned_h);
-     mp_image_clear(&img, 0, 0, img.w, img.h);
-     return true;
- }
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
deleted file mode 100644
index c2cacc3bff7a..000000000000
--- a/media-video/mpv/files/0.18.0/mpv-0.18.0-fix-initial-av-sync.patch
+++ /dev/null
@@ -1,42 +0,0 @@
-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;