Release Movit 1.5.0, including a small README update.

diff --git a/Makefile.in b/Makefile.in
index ad78e9d7418c00e37b24a24383290b76fb7a4003..926776683c935b45a21b5cc5e9d120906e116f64 100644 (file)
--- 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 360416e4a5eb7a3e304d39b374c698029daad3f6..4da5901b7577f943c5185e82c7f86122122127a4 100644 (file)
--- 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 c7b129a25b1d5db740bacc0fd7e65c63c36db46e..bc6a5a87a58e80c0ab4821888cfa6643d5f2d2e4 100644 (file)
--- 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