]> git.sesse.net Git - movit/blobdiff - README
Convert a loop to range-based for.
[movit] / README
diff --git a/README b/README
index 74be5e5f17bdb8af1d65ba1ded439a35e273ba90..dfddd7ad596dc633727cb718aa4e7e7bbadc0643 100644 (file)
--- a/README
+++ b/README
@@ -17,24 +17,21 @@ TL;DR, please give me download link and system demands
 
 OK, you need
 
-* A C++98 compiler. GCC will do. (I haven't tried Windows, but it
+* A C++11 compiler. GCC will do. (I haven't tried Windows, but it
   works fine on Linux and OS X, and Movit is not very POSIX-bound.)
 * GNU Make.
-* A GPU capable of running GLSL fragment shaders,
-  processing floating-point textures, and a few other things (all are
-  part of OpenGL 3.0 or newer, although most OpenGL 2.0 cards also
-  have what's needed through extensions). If your machine is less than five
-  years old _and you have the appropriate drivers_, you're home free.
+* A GPU capable of running OpenGL 3.0 or newer. GLES3 (for mobile devices)
+  will also work.
 * The [Eigen 3], [FFTW3] and [Google Test] libraries. (The library itself
   does not depend on the latter, but you probably want to run the unit tests.)
+  If you also have the Google microbenchmark library, you can get some
+  benchmarks as well.
 * The [epoxy] library, for dealing with OpenGL extensions on various
   platforms.
 
-Movit has been tested with Intel GPUs with the Mesa drivers
-(you'll probably need at least Mesa 8.0), Radeon 3850 and GeForce GTX 550
-on Linux with the manufacturer's drivers, and with GeForce 8800 on OS X.
-Again, most likely, GPU compatibility shouldn't be a big issue. See below
-for performance estimates.
+Movit has been tested with various Intel, AMD and NVIDIA GPUs, on Linux
+and Windows. Again, most likely, GPU compatibility shouldn't be a big issue.
+See below for performance estimates.
 
 
 Still TL;DR, please give me the list of filters
@@ -44,10 +41,10 @@ Blur, diffusion, FFT-based convolution, glow, lift/gamma/gain (color
 correction), mirror, mix (add two inputs), luma mix (use a map to wipe between
 two inputs), overlay (the Porter-Duff “over” operation), scale (bilinear and
 Lanczos), sharpen (both by unsharp mask and by Wiener filters), saturation
-(or desaturation), vignette, and white balance.
+(or desaturation), vignette, white balance, and a deinterlacer (YADIF).
 
 Yes, that's a short list. But they all look great, are fast and don't give
-you any nasty surprises. (I'd love to include denoise, deinterlace and
+you any nasty surprises. (I'd love to include denoise and
 framerate up-/downconversion to the list, but doing them well are
 all research-grade problems, and Movit is currently not there.)
 
@@ -55,8 +52,8 @@ all research-grade problems, and Movit is currently not there.)
 TL;DR, but I am interested in a programming example instead
 ===========================================================
 
-Assuming you have an OpenGL context already set up (currently you need
-a classic OpenGL context; a GL 3.2+ core context won't do):
+Assuming you have an OpenGL context already set up (either a classic OpenGL
+context, a GL 3.x forward-compatible or core context, or a GLES3 context):
 
 <code>
   using namespace movit;
@@ -92,16 +89,17 @@ 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 2014, so people want to edit HD video.
-* It's 2014, so everybody has a GPU.
-* It's 2014, so everybody has a working C++ compiler.
+* It's 2018, so people want to edit HD video.
+* It's 2018, so everybody has a GPU.
+* It's 2018, 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 2014
+While from a programming standpoint I'd love to say that it's 2018
 and interlacing does no longer exist, but that's not true (and interlacing,
 hated as it might be, is actually a useful and underrated technique for
-bandwidth reduction in broadcast video). Movit will eventually provide
-limited support for working with interlaced video, but currently does not.
+bandwidth reduction in broadcast video). Movit may eventually provide
+limited support for working with interlaced video; it has a deinterlacer,
+but cannot currently process video in interlaced form.
 
 
 What do you mean by “high-performance”?
@@ -113,22 +111,25 @@ is written using straight-up single-threaded, scalar C! Clearly there is
 room for improvement here, and that improvement is sorely needed.
 We want to edit 1080p video, not watch slideshows.
 
-Movit has chosen to run all pixel processing on the GPU, using GLSL—OpenCL is
-way too young, and CUDA is single-vendor (and also surprisingly hard to
-get good performance from for anything nontrivial). While “run on the GPU”
-does not equal “infinite speed” (I am fairly certain that for many common
-filters, I can beat the Intel-based GPU in my laptop with multithreaded SSE
-code on the CPU—especially as moving the data to and from the GPU has a cost that is not
-to be taken lightly), GPU programming is probably the _simplest_ way of writing
-highly parallel code, and it also frees the CPU to do other things like video
-decoding.
+Movit has chosen to run all pixel processing on the GPU, mostly using GLSL
+fragment shaders. While “run on the GPU” does not equal “infinite speed”,
+GPU programming is probably the _simplest_ way of writing highly parallel code,
+and it also frees the CPU to do other things like video decoding.
+
+Although compute shaders are supported, and can be used for speedups if
+available (currently, only the deinterlacer runs as a compute shader), it is
+surprisingly hard to get good performance for compute shaders for anything
+nontrivial. This is also one of the primary reasons why Movit uses GLSL and
+not any of the major GPU compute frameworks (CUDA and OpenCL), although it
+is also important that it is widely supported (unlike CUDA) and driver quality
+generally is fairly good (unlike OpenCL).
 
 Exactly what speeds you can expect is of course highly dependent on
 your GPU and the exact filter chain you are running. As a rule of thumb,
 you can run a reasonable filter chain (a lift/gamma/gain operation,
-a bit of diffusion, maybe a vignette) at 720p in around 30 fps on a two-year-old
+a bit of diffusion, maybe a vignette) at 720p in around 30 fps on a four-year-old
 Intel laptop. If you have a somewhat newer Intel card, you can do 1080p
-video without much problems. And on a mid-range nVidia card of today
+video without much problems. And on a low-range nVidia card of today
 (GTX 550 Ti), you can probably process 4K movies directly.
 
 
@@ -206,4 +207,5 @@ What do you mean by “open-source”?
 ==================================
 
 Movit is licensed under the [GNU GPL](http://www.gnu.org/licenses/gpl.html),
-either version 2 or (at your option) any later version.
+either version 2 or (at your option) any later version. You can find the full
+text of the license in the COPYING file, included with Movit.