Remove colorspace header reading

[GoogleCodeExporter]

This should never have been committed. The header introduced by xy-vsfilter 
cements ridiculously crappy hacks and semantics, and we don't want that.

The only sane way interpreting subtitle colors specified in RGB is RGB - 
surprising, huh?

I'd rather wait some years until xy-vsfilter get their stuff together rather 
than implementing these fragile hacks.

FYI, I actually attempted to implement support for this in mpv, but I gave up 
when I realized whata  load of crap this is.

Read commit message for details.

Original issue reported on code.google.com by nfxjfg@googlemail.com on 28 Jun 2013 at 6:39

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

> Is that so?

Yes, all Aegisub scripts are expected to be untouched RGB when explicitly 
tagged with a YCbCr Matrix other than TV.601.

As long as you don't force BT.601, Aegisub's ffmpegsource library automatically 
tags and uses the bitstream matrix and level range when available, otherwise 
guessing TV.709 by resolution (>=1024 width or >=600 height). Unless ffmpeg 
doesn't actually support the correct video matrix at all, this should hopefully 
always result in scripts with untouched RGB.

> That's a really big difference.

I also mentioned this in Comment #30?

Original comment by cyber.sp...@gmail.com on 5 Jul 2013 at 1:03

[GoogleCodeExporter]

> I also mentioned this in Comment #30?

It sounded like you were talking about the fact that Aegisub has a checkbox to 
force bt.601 only.

So let's just make this clear: if the subtitle track contains "YCbCr Matrix: 
tv.709", but the video uses BT.601, the file is considered broken?

Original comment by nfxjfg@googlemail.com on 5 Jul 2013 at 1:16

[GoogleCodeExporter]

If the video is 100% clearly BT.601 and the subtitle track is marked as TV.709 
then that could be considered broken, or at least very weird.

As I mentioned several times already, though, there are video tracks where it's 
not totally clear which is the right matrix to use. In such a situation Aegisub 
might treat the video as BT.709 and some other media player might instead 
choose BT.601. And in such a situation performing color correction still allows 
us to provide the end user with color matched subtitles.

Original comment by mad...@gmail.com on 5 Jul 2013 at 1:29

[GoogleCodeExporter]

I think using words as strong as "broken" to refer to this situation will only 
serve to increase confusion and mistrust in this discussion. I prefer to say:

> if the subtitle track contains "YCbCr Matrix: tv.709", but the video uses 
BT.601, the file is considered broken?

The file is considered bad manners.

Original comment by chortos@inbox.lv on 5 Jul 2013 at 1:36

[GoogleCodeExporter]

Well, either it's broken (doesn't follow the rules), or perfectly fine (follows 
the rules).

Using words like "bad manners" won't help much in a discussion about standards. 
You need _clear_ rules. Keep in mind, this is about whether a script with a 
"YCbCr Matrix" other than TV.601 uses colors in RGB or not. Judging from the 
previous comments, I assume it's "not" in general.

Original comment by nfxjfg@googlemail.com on 5 Jul 2013 at 1:45

[GoogleCodeExporter]

It is the aim to get colors to be native RGB whenever/whereever possible, so 
max compatability can be reached with the highest possible number of media 
players and subtitle renderers. However, in the short run ASS subtitle authors 
may still choose to use BT.601 for VSFilter compatability. Furthermore in 
situations where the matrix isn't 100% clear, the "YCbCr Matrix" tagging helps 
avoiding confusion. In all cases, properly interpreting the "YCbCr Matrix" 
field should only improve the situation to cover a few more corner cases...

Original comment by mad...@gmail.com on 5 Jul 2013 at 1:51

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

HTML5 style:

Authors SHOULD NOT make releases pairing video with ASS scripts with "YCbCr 
Matrix" that is not "TV.601" or "None" and is different from the video matrix.

Implementations MUST [or SHOULD if you insist] honour "YCbCr Matrix" and do 
RGB->YUV->RGB conversion even in these cases.

NOTE: [what madshi said about how the video matrix may be unclear].

Original comment by chortos@inbox.lv on 5 Jul 2013 at 2:07

[GoogleCodeExporter]

> It sounded like you were talking about the fact that Aegisub has a checkbox 
to force bt.601 only.

I was. If you disable the checkbox for force BT.601 only, you should end up 
with explicitly tagged scripts which are untouched RGB.

At the bare minimum, you really only need to support "TV.601" -> "Actual Video 
Matrix" mangled color scripts.

> So let's just make this clear: if the subtitle track contains "YCbCr Matrix: 
tv.709",
> but the video uses BT.601, the file is considered broken?

Technically, as far as the YCbCr Matrix header is concerned, there is no 
guarantee that such a script is actually broken. For YCbCr subtitle output, the 
header is supposed to be tagged as an authority under the assumption that the 
subtitle renderer has no knowledge of the actual video matrix.

Aegisub would not create such a script with "YCbCr Matrix: tv.709" on BT.601 
video though. So you would need to ask yourself, "Where did such a script come 
from, and for what purpose?". Any logic used for identifying broken scripts is 
outside the scope of what we've defined in the YCbCr Matrix header. None the 
less, Aegisub behavior is worth mentioning in your patch.

Original comment by cyber.sp...@gmail.com on 5 Jul 2013 at 2:09

[GoogleCodeExporter]

Then I'll add this to my patch as well:

+ * Note that newer Aegisub versions (the main application to produce ASS
+ * subtitle scripts) have an option that tries not to mangle the colors. It
+ * is said that if the header is not set to BT.601(TV), the colors are
+ * supposed not to be mangled, even if the "YCbCr Matrix" header is not
+ * set to "None". In other words, the video colorspace as detected by
+ * Aegisub is the same as identified in the file header.
+ *

Actually I have no idea how Aegisub behaves here, testing my copy of it I could 
make it write "None" as header value by unchecking the bt.601 force flag.

Original comment by nfxjfg@googlemail.com on 5 Jul 2013 at 5:04

[GoogleCodeExporter]

If you use a "Dummy Video", load a RGB video, or don't load any video at all, 
Aegisub will always write "YCbCr Matrix = None" to the script even if you have 
the Force BT.601 option set.

If you have "Force BT.601" disable in options and load a YCbCr Video, will 
always write the actual matrix and levels to the script.

This is intended behavior, but it depends on using the ffmpegsource (ffms2) 
video provider in Aegisub. On Windows, ffmpegsource is bundled with Aegisub and 
is set as the default video provider. I can't say I've ever verified if Aegisub 
has the same behavior on a non-Windows OS.

Original comment by cyber.sp...@gmail.com on 5 Jul 2013 at 10:49

[GoogleCodeExporter]

Pushed the latest patch. Discussion over, everyone go home.

I regret a bit that I couldn't remove the header, but there was too much 
resistance from all sides.

Original comment by nfxjfg@googlemail.com on 6 Jul 2013 at 12:22

• Changed state: Fixed