Release Movit 1.5.0, including a small README update. 1.5.0
authorSteinar H. Gunderson <sgunderson@bigfoot.com>
Tue, 21 Mar 2017 18:39:51 +0000 (19:39 +0100)
committerSteinar H. Gunderson <sgunderson@bigfoot.com>
Tue, 21 Mar 2017 18:40:17 +0000 (19:40 +0100)
Makefile.in
NEWS
README

index ad78e9d..9267766 100644 (file)
@@ -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 (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 c7b129a..bc6a5a8 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