Revert "sub: support straight alpha additionally to premultiplied alpha"

This reverts commit 689a25003fc8098e5fdfbb2faefc0e18365d3acb, with some
adjustments to code that was added after that commit.

I just messed up big time. We don't need this, and in fact the commit
confused straight and premultiplied alpha at one point (just a simple
inverted condition due to an oversight), which is why it looked like
it was working.

In commit 2827295 I wrote:

   Also, libva can't decide whether it accepts straight or premultiplied
   alpha for OSD sub-pictures [...]

That was just me messing up and being severely confused by my own bugs.
VA API  uses premultiplied alpha, which by the way is nice and
thoughtful of the VA API devs.

Well, this was stupid. But in the end, I'm glad that I could actually
reduce codesize by a good amount again.

1 files changed, 3 insertions, 3 deletions

diff --git a/sub/sub.h b/sub/sub.h
index 3463022c88..3cb140565c 100644
--- a/sub/sub.h
+++ b/sub/sub.h
@@ -25,12 +25,11 @@
 
 #include "mpvcore/m_option.h"
 
-// NOTE: VOs must support at least SUBBITMAP_RGBA or SUBBITMAP_RGBA_STR.
+// NOTE: VOs must support at least SUBBITMAP_RGBA.
 enum sub_bitmap_format {
     SUBBITMAP_EMPTY = 0,// no bitmaps; always has num_parts==0
     SUBBITMAP_LIBASS,   // A8, with a per-surface blend color (libass.color)
     SUBBITMAP_RGBA,     // B8G8R8A8 (MSB=A, LSB=B), scaled, premultiplied alpha
-    SUBBITMAP_RGBA_STR, // like RGBA, but straight (not premultiplied) alpha
     SUBBITMAP_INDEXED,  // scaled, bitmap points to osd_bmp_indexed
 
     SUBBITMAP_COUNT
@@ -39,7 +38,8 @@ enum sub_bitmap_format {
 // For SUBBITMAP_INDEXED
 struct osd_bmp_indexed {
     uint8_t *bitmap;
-    // Each entry is like a pixel in SUBBITMAP_RGBA_STR format.
+    // Each entry is like a pixel in SUBBITMAP_RGBA format, but using straight
+    // alpha.
     uint32_t palette[256];
 };