From: Steinar H. Gunderson <sgunderson@bigfoot.com>
Date: Tue, 21 Mar 2017 18:39:51 +0000 (+0100)
Subject: Release Movit 1.5.0, including a small README update.
X-Git-Tag: 1.5.0
X-Git-Url: https://git.sesse.net/?p=movit;a=commitdiff_plain;h=refs%2Ftags%2F1.5.0

Release Movit 1.5.0, including a small README update.
---

diff --git a/Makefile.in b/Makefile.in
index ad78e9d..9267766 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -6,8 +6,8 @@ GTEST_DIR ?= /usr/src/gtest
 # strive towards having a rock-stable ABI, but at least the soversion will increase
 # whenever it breaks, so that you will not have silent failures, and distribution package
 # management can run its course.
-movit_ltversion = 5:0:0
-movit_version = 1.4.0
+movit_ltversion = 6:0:0
+movit_version = 1.5.0
 
 prefix = @prefix@
 exec_prefix = @exec_prefix@
diff --git a/NEWS b/NEWS
index 360416e..4da5901 100644
--- a/NEWS
+++ b/NEWS
@@ -1,3 +1,24 @@
+Movit 1.5.0, March 21st, 2017
+
+  - Support interleaved Y'CbCr input (4:4:4 in a single texture).
+
+  - Support 10-bit and 12-bit Y'CbCr, both for input and output. For planar,
+    these are supported packed in 16-bit ints; for interleaved, 10:10:10:2 is
+    supported. (Efficient conversion to and from v210, ie. 10-bit 4:2:2,
+    is possible using compute shaders, but Movit does not include support
+    for them at the current point.) Note that this now means the num_levels
+    flag in YCbCrFormat actually matters, although 0 will be interpreted
+    as 256 (8-bit) for the benefit of older applications.
+
+  - Limited support for having multiple Y'CbCr outputs from a chain.
+
+  - Allow changing the Y'CbCr output coefficients runtime, ie., after finalize.
+
+  - Fix an issue where the last pass would have been rendered with the sRGB
+    flag set, which confused Qt applications running in certain NVIDIA
+    configurations.
+
+
 Movit 1.4.0, November 5th, 2016
 
   - Allow setting the intermediate format for chains, instead of hardcoding
diff --git a/README b/README
index c7b129a..bc6a5a8 100644
--- a/README
+++ b/README
@@ -89,9 +89,9 @@ OK, I can read a bit. What do you mean by “modern”?
 Backwards compatibility is fine and all, but sometimes we can do better
 by observing that the world has moved on. In particular:
 
-* It's 2016, so people want to edit HD video.
-* It's 2016, so everybody has a GPU.
-* It's 2016, so everybody has a working C++ compiler.
+* It's 2017, so people want to edit HD video.
+* It's 2017, so everybody has a GPU.
+* It's 2017, so everybody has a working C++ compiler.
   (Even Microsoft fixed theirs around 2003!)
 
 While from a programming standpoint I'd love to say that it's 2016