GoogleCodeExporter
commented
8 years ago Original comment by nfxjfg@googlemail.com on 28 Jun 2013 at 6:40
Attachments:
Closed GoogleCodeExporter closed 8 years ago
GoogleCodeExporter
commented
8 years ago Original comment by nfxjfg@googlemail.com on 28 Jun 2013 at 6:40
Attachments:
GoogleCodeExporter
commented
8 years ago Nope.
Honestly, it sounds like you failed to implement a feature and are trying to
blame the feature itself. I may be sloppy about submitting patches upstream
(which I know is bad, but let's not focus on this), but my local mplayer2 build
has supported the colorspace header in vf_ass for many months with no problems
at all. Why only in vf_ass? Merely because when I was doing it, I didn't know
any OpenGL. By now I've hacked vo_gl3 a lot (expect patches both to mplayer2
and to mpv at some point) and I'm confident that adding colorspace header
support to vo_gl3 is pretty much trivial. You just add a YUV rendering path to
the EOSD shader exactly like the one in the video shader.
In fact, you want to copy the whole rendering path including gamma adjustments
and everything *in any case*, because :typesetting:.Original comment by chortos@inbox.lv on 28 Jun 2013 at 7:52
GoogleCodeExporter
commented
8 years ago >Honestly, it sounds like you failed to implement a feature and are trying to
blame the feature itself.
It worked pretty well, but required some hacks at which point I decided not to
push it.
>I'm confident that adding colorspace header support to vo_gl3 is pretty much
trivial. You just add a YUV rendering path to the EOSD shader exactly like the
one in the video shader.
That's a big WTF, and also much less efficient. We can draw RGB on the screen.
Messing up the whole rendering path just because vsfilter sucks? No, just no.
What's next, rendering the subs before scaling to emulate the blurry appearance
of vsfilter? Anyway, this is offtopic.
>In fact, you want to copy the whole rendering path including gamma adjustments
and everything *in any case*, because :typesetting:.
True, in theory it should render the subs onto a screen size frame buffer and
then do the post processing. But it's also slower.Original comment by nfxjfg@googlemail.com on 28 Jun 2013 at 8:08
GoogleCodeExporter
commented
8 years ago >I may be sloppy about submitting patches upstream (which I know is bad, but
let's not focus on this),
PS: your patch was perfectly fine. However, xy-vsfilter semantics are not.
The main reason why you should not like this is because it actively encourages
creating broken files (such as BT.601 mangled RGB on BT.709 video), instead of
adhering to sanity.Original comment by nfxjfg@googlemail.com on 28 Jun 2013 at 8:11
GoogleCodeExporter
commented
8 years ago > Messing up the whole rendering path just because vsfilter sucks?
No. Not because VSFilter sucks, but because this is what ASS scripts expect.
Are you making a real-world ASS renderer or a useless piece of software nobody
wants?
Besides, you're not "messing up" the rendering path. You're just adding a new
one. Moreover, subtitle formats exist that are actually properly native YUV, so
if you ever want to correctly support those in mpv, you will need a YUV
subtitle rendering path anyway.
> What's next, rendering the subs before scaling to emulate the blurry
appearance of vsfilter?
That's not next. That's now. Because currently it's the only way to correctly
render colours in 99% of ASS scripts in existence. (And I personally believe
this is the right way for sign typesetting anyway because it's aimed to
perfectly blend in with the video, but I can live with rescaling everything.)
> broken files (such as BT.601 mangled RGB on BT.709 video)
The files are not broken. The file format is. But supporting this file format
is the whole point of libass.
> True, in theory it should render the subs onto a screen size frame buffer and
then do the post processing. But it's also slower.
But it's also correct. In my book, correctness trumps speed.Original comment by chortos@inbox.lv on 28 Jun 2013 at 8:44
GoogleCodeExporter
commented
8 years ago Slight adjustment for precision:
> the only way to correctly render colours in 99% of ASS scripts in existence
...on non-BT.601 video.Original comment by chortos@inbox.lv on 28 Jun 2013 at 8:51
GoogleCodeExporter
commented
8 years ago >No. Not because VSFilter sucks, but because this is what ASS scripts expect.
Are you making a real-world ASS renderer or a useless piece of software nobody
wants?
If you want perfect compatibility, I recommend running vsfilter in wine. You
can use pipes or shared memory to transfer the video.
>Besides, you're not "messing up" the rendering path. You're just adding a new
one. Moreover, subtitle formats exist that are actually properly native YUV, so
if you ever want to correctly support those in mpv, you will need a YUV
subtitle rendering path anyway.
Unneecessary complexity to support fringe use cases. There are no subtitle
formats that actually use per-pixel YUV. There is no libavcodec subtitle
decoder that outputs YUV.
>Because currently it's the only way to correctly render colours in 99% of ASS
scripts in existence.
Enjoy your obsession with trying to emulate vsfilter correctly. Again, just use
wine.
>The files are not broken. The file format is.
ASS originally specified RGB, that's it. The breakage only happened as HD video
became popular, and then xy-vsfilter added a horrible hack to the file format
in the name of bug-for-bug backwards compatibility. I do not want to support
this. It's still not too late to stop this.
For converting broken old subtitles, this project can be used:
https://github.com/pigoz/smart_ass
>But it's also correct. In my book, correctness trumps speed.
Patch welcome. But on the other hand, people prefer realtime playback over 100%
correct rendering, so it should be optional.Original comment by nfxjfg@googlemail.com on 28 Jun 2013 at 8:58
GoogleCodeExporter
commented
8 years ago Am I supposed to say "enjoy your useless piece of software nobody wants" then?
> If you want perfect compatibility, I recommend running vsfilter in wine. You
can use pipes or shared memory to transfer the video.
Thanks, I'll just reboot to Windows. Or use my patched libass and mplayer2,
which work just fine. (Besides, VSFilter had huge problems with fonts when I
tried it under Wine once. But that was several years ago, and the issues may
have been resolved by now.)
> Unneecessary complexity to support fringe use cases. There are no subtitle
formats that actually use per-pixel YUV. There is no libavcodec subtitle
decoder that outputs YUV.
Necessary complexity, and totally not a fringe use case. Seriously: literally
almost every ASS file in existence uses BT.601.
> There are no subtitle formats that actually use per-pixel YUV. There is no
libavcodec subtitle decoder that outputs YUV.
I'm not sure what you mean by per-pixel. ASS doesn't have per-pixel colours.
DVD and Blu-ray subtitles are native YUV. libavcodec outputs them as RGB, yes.
Why? Because it internally converts them to RGB using BT.601. This is, of
course, incorrect and should be fixed sometime.
> Enjoy your obsession with trying to emulate vsfilter correctly.
Thanks. But I'm not emulating VSFilter just because it's VSFilter. I'm not
emulating border non-rotation, for example. I just like my colours and blurs as
intended.
> For converting broken old subtitles
Broken old subtitles are the ones using BT.709. Both correct and new subtitles
are all BT.601.
> ASS originally specified RGB, that's it.
It matters absolutely nothing what ASS originally specified.
If you want to be pedantic, ASS was never actually specified in enough detail.
All the "specification" said was that the colour is RGB. What sort of RGB? No
particulars were given.
Of course, in practice everyone agrees that ASS meant painting the RGB values
on top of the video converted to RGB before any gamma and gamut correction.
(Which, as noted in the above posts, is actually not what mplayer2 and mpv do.
Just saying.) But it matters none. All real-world input uses BT.601. That's it.
> The breakage only happened as HD video became popular
Yes.
> and then xy-vsfilter added a horrible hack to the file format in the name of
bug-for-bug backwards compatibility.
Yes. Which is actually the solution for the future, not the past. Even if this
header didn't exist, mplayer clones and VLC would still have to default to
BT.601 to produce correct output for any real-world input.
> It's still not too late to stop this.
It is. It is now many years too late. Indeed, even if it weren't late, libass
alone would still have no power to stop this whatsoever. Indeed, you could say
libass has been trying to stop this for all these years; very clearly, it has
not succeeded.
At the same time, the new header *is* in some sense stopping this: you can now
have scripts with untouched RGB that are reliably correct in all renderers. I
don't like the exact form the header takes either, but as I've said before,
this is the only version that people were willing to accept at all, all sides
having made plenty of concessions. If not for this, we would still be stuck in
a BT.601-only world.Original comment by chortos@inbox.lv on 28 Jun 2013 at 10:18
GoogleCodeExporter
commented
8 years ago That's a lot of discussion going on here. I agree that the colorspace header is
a bad idea. The header shouldn't be necessary for perfect correct rendering.
Conversions between YCbCr and RGB colorspaces are accurately specified.
It's good and fine to strive for compatibility, but you clearly have to stop
somewhere, or you'll end up with unmaintainable, fragile and complex code at
some point. Think about what would have happened with Web browsers if they just
kept on adding features and hacks to deal with all "legacy" HTML after the
first browser wars. Instead of adding hacks upon hacks to the renderer, the
subtitle files should be fixed. I think nfxjfg already pointed you in the right
direction. :)
As for the header itself, I am in favor of removing it, too.Original comment by g...@chown.ath.cx on 28 Jun 2013 at 10:36
GoogleCodeExporter
commented
8 years ago >Am I supposed to say "enjoy your useless piece of software nobody wants" then?
From what I know, only anime actually relies on this issue. It works perfectly
well for anything else.
>Thanks, I'll just reboot to Windows.
If that works for you, fine.
>Necessary complexity, and totally not a fringe use case.
Yes, yes, it is. This colorspace stuff is completely broken. It's insane. It
should be fixed before it spreads. xy-vsfilter and Aegisub chose to make the
broken case the default, so for now anything using libass will be broken
(unless they implement this mess), but just give it a few years, maybe things
will become sane again. If not, who cares anyway.
>DVD and Blu-ray subtitles are native YUV. libavcodec outputs them as RGB, yes.
Why? Because it internally converts them to RGB using BT.601. This is, of
course, incorrect and should be fixed sometime.
These things use strictly specified colorspaces for conversion, so they're not
broken.
>Broken old subtitles are the ones using BT.709. Both correct and new subtitles
are all BT.601.
This is the most messed up statement I've heard for a long time. Why would
intentionally mangled RGB be the non-broken case?
By the way, I find your use of BT.601 for RGB confusing. It only makes sense in
context of the "YCbCr Matrix" ASS header. Is it right that it specifies a
conversion relative to the video colorspace (RGB -> BT.601 -> (video colorspace
to RGB) -> output), or does the ASS header actually specify a fixed matrix for
AS->RGB? Well, I'm quite sure it does (it wouldn't be such a mess otherwise),
so what you have to say is: "the inverse of RGB which was converted to BT.601
and then back using the video colorspace of the video it was being designed for"
Now what makes me freak out is that ASS apparently doesn't allow using sRGB as
colorspace, making fixing the situation completely impossible. Just no.
While a hack to get old subs display correctly isn't so bad, it should not be
default.
>If you want to be pedantic, ASS was never actually specified in enough detail.
All the "specification" said was that the colour is RGB. What sort of RGB? No
particulars were given.
From what I heard Substation Alpha was a Visual Basic program. As such, it used
RGB in combination with Microsoft APIs, which have been specified to use in
sRGB since 1996.
>Which is actually the solution for the future, not the past.
A completely broken solution.
>I don't like the exact form the header takes either,
If you argue like this, we wouldn't have needed the header. We'd just stick to
BT.601 mangled RGB. In fact, the header makes it much worse by allowing for
example using BT.709 mangled RGB with BT.601 video (which makes no sense, but
which you must support if you honor this header). At the same time, using
"none" for the header literally makes no sense (it's defined to be arbitrary),
and there's no way to use sRGB.
Why was this header introduced again?
This is broken. The only sensible thing to do is rejecting it.Original comment by nfxjfg@googlemail.com on 28 Jun 2013 at 11:48
GoogleCodeExporter
commented
8 years ago PS: I have the same opinion about ass_set_storage_size().
Original comment by nfxjfg@googlemail.com on 28 Jun 2013 at 11:54
GoogleCodeExporter
commented
8 years ago > Think about what would have happened with Web browsers if they just kept on
adding features and hacks to deal with all "legacy" HTML after the first
browser wars. Instead of adding hacks upon hacks to the renderer, the subtitle
files should be fixed.
Thanks for mentioning HTML. Okay. Browsers *did* keep on adding features and
hacks to deal with all legacy HTML. Quirks mode is strictly defined in HTML5
and is a core part of the specification. Error handling is strictly defined in
HTML5 and is a core part of the specification. Think about what would have
happened if browsers *hadn't* done this. W3C said HTML was no good and started
XHTML2. Where is XHTML2 now?
Why don't we take a page from Web browser developers' book?
Unlike the traditional parts of ASS, the new header actually has a rather
strict definition and implicitly brings with it an equally strict definition of
colour values.
> It's good and fine to strive for compatibility, but you clearly have to stop
somewhere, or you'll end up with unmaintainable, fragile and complex code at
some point.
The colorspace header is trivial to support. Seriously. We already have all
neccessary support in libass, and is it hard to maintain?
> I think nfxjfg already pointed you in the right direction. :)
Unfortunately, I don't see any pointers. All he's saying is he doesn't like the
current solution.
> From what I know, only anime actually relies on this issue. It works
perfectly well for anything else.
And what else uses ASS?
> It should be fixed before it spreads. xy-vsfilter and Aegisub chose to make
the broken case the default
There is nothing to spread to. VSFilter variants have a monopoly on the
subtitle renderer market, and libass is the only competitor. Aegisub is the
only subtitle editor with no competitors at all.
> for now anything using libass will be broken (unless they implement this
mess), but just give it a few years, maybe things will become sane again.
A few years have already passed.
> If not, who cares anyway.
This is how I see what you are saying:
"I don't like this concept that everyone uses. Let's drop support for it! The
average Joe will think that the resulting issues are their own fault rather
than that of libass or mplayer/VLC, so we can get away with this."
>> DVD and Blu-ray subtitles are native YUV. libavcodec outputs them as RGB,
yes. Why? Because it internally converts them to RGB using BT.601. This is, of
course, incorrect and should be fixed sometime.
> These things use strictly specified colorspaces for conversion, so they're
not broken.
They use the colorspace of the video. In terms of the new header, "None". The
point is, it's native YUV. You'll want to convert it from YUV to RGB at some
point, and the video matrix is involved in this. Just like ASS!
> Why would intentionally mangled RGB be the non-broken case?
It's a vicious circle. This is the default behaviour of all software except
libass, which has very little market share, so typesetters aim for mangled RGB.
Typesetters aim for mangled RGB, so files aim for mangled RGB. (Extra link: old
typesetters teach new ones to use mangled RGB.) Files aim for mangled RGB, so
this is the default behaviour.
> "the inverse of RGB which was converted to BT.601 and then back using the
video colorspace of the video it was being designed for"
Yes, precisely. In practice, because of Aegisub, it would be even more precise
to say "the subtitles are designed to be blended onto the video which was
converted to RGB using BT.601 rather than the proper associated matrix". But
the header's definition is exactly what you wrote.
> From what I heard Substation Alpha was a Visual Basic program. As such, it
used RGB in combination with Microsoft APIs, which have been specified to use
in sRGB since 1996.
I imagine subtitle rendering was not done using Microsoft APIs, so this is not
very relevant. Not to mention that the SSA software many years ago has no
relevance on the ASS format now. Or that Aegisub has been the new SSA for
almost as many years.
> If you argue like this, we wouldn't have needed the header. We'd just stick
to BT.601 mangled RGB.
That's my line.
> In fact, the header makes it much worse by allowing for example using BT.709
mangled RGB with BT.601 video (which makes no sense, but which you must support
if you honor this header).
True. This is why I said I would have preferred the header to take a simpler
form preventing this. But a header that formalizes the existing behaviour and
allows interoperable sane behaviour is closer to your ideal than no header and
sticking to BT.601.
I've said this before and I'll say this again: read the relevant discussion
thread on xy-VSFilter. The developers/spokespersons of xy-VSFilter, Aegisub,
the internal subtitle renderer of MPC-HC, LAV Filters and madVR (and I may well
be forgetting someone), as well as interested third parties (I can remember at
least one typesetter), started with the common goal of fixing the broken
treatment of colour values in ASS. They spent tons of time, wrote tons of
posts, surely felt tons of anger at each other, were on the verge of dropping
out entirely (and sticking to BT.601 mangled RGB) more than once each. They
made tons of concessions, and the header we have now is the only thing that
they managed to agree on. Some of these people share the view that ASS should
simply always use plain RGB except in old files. You are definitely not alone
in this. But if there was to be any solution at all, this was it.
You're rejecting a step towards your ideal in hopes of instead making the whole
way with a single leap. And the step was made by everyone around you, while the
leap you'll be making alone.
> using "none" for the header literally makes no sense (it's defined to be
arbitrary)
No. Thanks to madshi's efforts, it's defined to untouched RGB. Exactly what you
want.
> Now what makes me freak out is that ASS apparently doesn't allow using sRGB
as colorspace
"None" is untouched RGB. In more words, quoting myself, "painting the RGB
values on top of the video converted to RGB [using whatever matrix] before any
gamma and gamut correction".
And since we're somehow being pointlessly pedantic, I'll point out that sRGB is
rarely used for video. I imagine things like non-photographic CGI may use it,
but other RGB variants would be more useful in general.
> Why was this header introduced again?
What.Original comment by chortos@inbox.lv on 28 Jun 2013 at 2:13
GoogleCodeExporter
commented
8 years ago >This is how I see what you are saying:
>"I don't like this concept that everyone uses. Let's drop support for it! The
average Joe will think that the resulting issues are their own fault rather
than that of libass or mplayer/VLC, so we can get away with this."
No. What I'm saying is more like: "fuck vsfilter"
This is not a popularity contest. I don't care _that_ much whether users want
to use my software or not, as long as it works for me. Besides, I bet VLC has a
larger userbase than mpc-hc. No, I don't want to implement crap-hacks to
attract a cargo culting userbase. They'll just be disappointed that libass is
not exactly vsfilter anyway.
Sometimes you're much better off not to follow the "standard", or trying to
catch up to a bigger competitor. I think that's what Greg wanted to say when
bringing up HTML.
>The point is, it's native YUV.
There is no native YUV in ASS.
>This is the default behaviour of all software except libass, which has very
little market share, so typesetters aim for mangled RGB.
I know. People always keep creating broken files. But if I can get at least
some people to at least think about it once more, my goal is already reached.
Also, if they _really_ care, they can create files that happen to work with
both libass and xy-vsfilter.
>I've said this before and I'll say this again: read the relevant discussion
thread on xy-VSFilter.
tl;dr
>The developers/spokespersons of xy-VSFilter, Aegisub, the internal subtitle
renderer of MPC-HC, LAV Filters and madVR (and I may well be forgetting
someone), as well as interested third parties (I can remember at least one
typesetter), started with the common goal of fixing the broken treatment of
colour values in ASS. They spent tons of time, wrote tons of posts, surely felt
tons of anger at each other, were on the verge of dropping out entirely (and
sticking to BT.601 mangled RGB) more than once each.
Unfortunately I have to say that the result is a really big load of crap.
>"None" is untouched RGB.
Last I looked xy-vsfilter did not implement "None" correctly. It still
BT.601-mangles it. This is in fact my main issue with this stuff. If you follow
the header's semantics, there is literally no way to create files that are
independent of subtitle renderer and video colorspace. I wouldn't mind optional
optional hacks to support old scripts, but purposedly messing up new scripts is
just too much.
If xy-vsfilter and Aegisub associate sane semantics with "None" and start using
it by default, sure, that would be awesome.
>And since we're somehow being pointlessly pedantic, I'll point out that sRGB
is rarely used for video.
Sure, there are monitors that are not sRGB. But I've never seen a YUV or
RGB-as-BT.601-mangled monitor.
PS: I wonder what your mplayer hack does if the video has been converted to RGB
by a video filter?Original comment by nfxjfg@googlemail.com on 28 Jun 2013 at 2:57
GoogleCodeExporter
commented
8 years ago OK here's a new, slightly less offensive patch.
I hope this is enough to discourage anyone from implementing this non-sense.Original comment by nfxjfg@googlemail.com on 28 Jun 2013 at 4:29
Attachments:
GoogleCodeExporter
commented
8 years ago It seems like there are some misunderstandings about the header, which I should
probably clear up.
___
"YCbCr Matrix" header defines subtitle RGB -> subtitle YCbCr output only.
If you want RGB subtitle output to match YCbCr subtitles output with the "YCbCr
Matrix" tags, some color corrections would be needed:
A) Pre-process for the subtitle colors for "YCbCr Matrix" prior rendering the
subtitles as RGB bitmaps. XySubFilter supports this.
or
B) Render subtitles directly as RGB and then correct them for "YCbCr Matrix".
madVR supports this via GPU shaders.
___
"YCbCr Matrix = None" defines untouched RGB subtitles only.
It specifies that the script was authored with untouched RGB colors. If it
matches the video or not, will depend on with the media player's video renderer
correctly converts a video from YCbCr -> RGB with the correct matrix, also
resulting in untouched RGB.
How Libass outputs RGB subtitles is already 100% complaint with "YCbCr Matrix =
None", so no change is required to support "None".
___
Video YCbCr -> Video RGB is always expected to use the actual video matrix, as
normal.
___
VSFilter (legacy) has always output TV.601 YCbCr subtitles.
VSFilter (legacy) has always output untouched RGB subtitles.
[A future release of xy-VSFilter will likely support the "YCbCr Matrix" tags
for RGB output as well, so we can match the colors of YCbCr output like
XySubFilter does]
___
> Last I looked xy-vsfilter did not implement "None" correctly.
> It still BT.601-mangles it. This is in fact my main issue with this stuff.
This is a bug and absolutely not intended behavior of the tags. We should
hopefully have this fixed very soon. It was only brought to our attention a
couple week ago. The last time I tested this it was working, but sometime
between the test versions and release it got broken...
> It worked pretty well, but required some hacks at which point I decided not
to push it.
It will be unfortunate if mpv won't support this, but from the start I only
expected players which support Libass to only support "YCbCr Matrix = None"
(i.e. no change in behavior) because I'd was assuming there would be objections
like you've raised.
Yet if the hacks you are referring is xy-VSFilter's current bug with "YCbCr
Matrix = None", there is no need to copy this. Any bugs in our implementation
of "YCbCr Matrix" compared to how the "YCbCr Matrix" tags were defined, will be
fixed if reported to us.Original comment by cyber.sp...@gmail.com on 29 Jun 2013 at 1:09
GoogleCodeExporter
commented
8 years ago Well, that's exactly what I wrote in the second patch, except about "None". On
the cccp forum you wrote about it:
>Of course "YCbCr Matrix = None" is valid, but the agreed spec was also based
around tagging the YCbCr Matrix explicitly whenever you had a script which was
color critical. "YCbCr Matrix = None" is nothing but a best-effort, non
color-critical tag, with no guarantee of script portability on anything but
native RGB video. Will it produce correct colors sometimes, sure.
This sounds exactly like the opposite you said. So which one is it?
Also, let me repeat that the way this colorspace problem was "solved" is
utterly braindead. The only way to fix this would be associating sane semantics
with None and using it everywhere by default.Original comment by nfxjfg@googlemail.com on 29 Jun 2013 at 12:44
GoogleCodeExporter
commented
8 years ago > This sounds exactly like the opposite you said. So which one is it?
I don't see how that is any different from what I said above. "YCbCr Matrix =
None" is untouched RGB.
> best-effort, non color-critical tag, with no guarantee of script
> portability on anything but native RGB video
> Will it produce correct colors sometimes, sure.
All I was expressing here were the general limitations of untouched RGB
subtitles, in terms of color matching to a YCbCr with a bitstream matrix flag
which cannot be guessed by resolution. Most video renderers do not support
honoring bitstream matrix for YCbCr->RGB. Use of untouched RGB subtitles means
there is no guarantee that the relationship of subtitle colors to the video
colors will be correct. YCbCr Matrix explicit tagging was designed to allow
working around the limitations of untouched RGB subtitle output, as well as
allow simplified YCbCr subtitle output.
> The only way to fix this would be associating sane semantics
No matter what semantics are assigned, without the potential for color
correction there is no way to guarantee that scripts will actually match the
video it was authored to, especially when the majority of video decoders &
video renderer YCbCr -> RGB conversions do not support honoring bitstream
matrix flags. I seems to remember that ffmpeg swscale and some mplayer stuff
defaulted to using BT.601 for everything as well.Original comment by cyber.sp...@gmail.com on 29 Jun 2013 at 2:58
GoogleCodeExporter
commented
8 years ago >without the potential for color correction there is no way to guarantee that
scripts will actually match the video it was authored to
So why is it suddenly our task to make subtitles display correctly, if the
video renderers can not display video correctly?
Correct subs but incorrectly displayed video, hurray!Original comment by nfxjfg@googlemail.com on 29 Jun 2013 at 3:06
GoogleCodeExporter
commented
8 years ago > So why is it suddenly our task to make subtitles display correctly,
>if the video renderers can not display video correctly?
Video Render goal = Ensure that videos display to the viewer as intended by the
author.
Subtitle Render goal = Ensure that subtitles display to the viewer as intended
by the author.
> Correct subs but incorrectly displayed video, hurray!
Better than the alternative. Why should we care if the video renderer is doing
completely incorrect as long as subtitle viewing experience remains optimal?
It's completely out-of-scope for us to go around and fix every broken video
renderer just so untouched RGB subtitles display as intended the majority of
the time.Original comment by cyber.sp...@gmail.com on 29 Jun 2013 at 3:59
GoogleCodeExporter
commented
8 years ago >Why should we care if the video renderer is doing completely incorrect as long
as subtitle viewing experience remains optimal? It's completely out-of-scope
for us to go around and fix every broken video renderer just so untouched RGB
subtitles display as intended the majority of the time.
It's out-of-scope for a subtitle renderer to care about broken video renderers.
Anyway, you could still do that video-renderer specific color compensation
WITHOUT MESSING WITH THE SUBTITLE FORMAT.Original comment by nfxjfg@googlemail.com on 29 Jun 2013 at 4:10
GoogleCodeExporter
commented
8 years ago > It's out-of-scope for a subtitle renderer to care about broken video
renderers.
Which is exactly why we don't care about broken video renderers. What we care
about is that subtitles can be display as expected by the script author,
without potentially inaccurate guessing.
> Anyway, you could still do that video-renderer specific color compensation
> WITHOUT MESSING WITH THE SUBTITLE FORMAT.
It's out-of-scope for a subtitle renderer to care about broken video renderers.
If you like, "YCbCr Matrix" could be thought of as nothing more than an
informative tag which says:
"This script was authored to YCbCr video which was converted to RGB using XXX
matrix".
Harmless right?
Such information makes YCbCr subtitle rendering 100% reliable on the original
authored video, allows 100% reliable support of legacy VSFilter scripts, and
eliminates confusion in identifying scripts which are not TV.601. I fail to see
how providing this information about how a script was authored is harmful to
the subtitle format.Original comment by cyber.sp...@gmail.com on 29 Jun 2013 at 5:03
GoogleCodeExporter
commented
8 years ago >I fail to see how providing this information about how a script was authored
is harmful to the subtitle format.
Because it forces everyone to specify RGB in some ridiculous mangled colorspace
(which is not exactly RGB but almost), and completely fails if you exchange the
video?
As for putting information into the ASS script how the video was created: yes,
it would be useful how the script was created. But the current headers are
missing a very critical part: absolute information about how the RGB colors
were messed. It forces you to know the colorspace used for video conversion to
get 100% matching colors. I know, classic vsfilter had this issue in some
cases. But why are you so proud that you "formalized" this bug and force
everyone to use it?
And let me just ask you: why is sRGB not enough for you? sRGB specifies color
reliably everywhere (that's what sRGB was made for), and you can convert it to
the video colorspace too if you want. This will in fact be fine even with
thouroughly messed up video renderers, as they will not provide any sort of RGB
overlay that xy-vsfilter will use. MadVR is the only case where there could be
a possible mismatch between YUV and RGB, but I'm sure you can rely on MadVR to
get this stuff right.Original comment by nfxjfg@googlemail.com on 29 Jun 2013 at 5:36
GoogleCodeExporter
commented
8 years ago > Because it forces everyone to specify RGB in some ridiculous mangled
> colorspace (which is not exactly RGB but almost), and completely fails
> if you exchange the video?
Does it? The main difference between before we introduced the YCbCr Matrix tags
and after, is that now you have a way to correct RGB colors if you wanted to.
That Aegisub has always defaulted to BT.601 to be compatible with VSFilter
behavior is nothing new. Nothing has really changed in that regard, except now
that are actually labeled as such.
If you wanted, you could use "YCbCr Matrix = None" to allow exchanging the
video, as you already seem fine with untouched RGB subtilte colors sometimes
not matching the video when the video renderer is at fault. Otherwise, your
script can still be untouched RGB with the matrix explicitly tagged, and it
takes all of 2 seconds to change the header to the matrix of the new video.
Otherwise, we really didn't go out of our way to add other any new
functionality not related to subtitle colors.
> But the current headers are missing a very critical part: absolute
information about how the RGB colors were messed.
What do you mean by this? This sounds vaguely similar to something I originally
proposed when the YCbCr Matrix header was being debated and defined, but
everybody else rejected it for being too complex.
> But why are you so proud that you "formalized" this bug and force everyone to
use it?
What bug did we formalize exactly? The intention was that we "fixed" this old
bug in VSFilter so everybody would _not_ have to mimic it any longer, and
authored for Libass or MPC-HC ISR without worry of compatibility. The YCbCr
Matrix header does not have a default value, and doesn't really enforce any
behavior either. It just exposes a piece of information which has always
existed, but been hidden.
> why is sRGB not enough for you?
When you say sRGB, do you mean untouched RGB? ASS subtitles do not define a
gamut or gamma for RGB colors.
> sRGB specifies color reliably everywhere (that's what sRGB was made for), and
you can convert it to
> the video colorspace too if you want. This will in fact be fine even with
thouroughly messed up video renderers,
> as they will not provide any sort of RGB overlay that xy-vsfilter will use.
Could you clarify what you are talking about here?Original comment by cyber.sp...@gmail.com on 29 Jun 2013 at 6:30
GoogleCodeExporter
commented
8 years ago >When you say sRGB, do you mean untouched RGB? ASS subtitles do not define a
gamut or gamma for RGB colors.
sRGB does.
>Could you clarify what you are talking about here?
A sane rendering path? The xy-vsfilter bit is a bit out of context. I was
saying that only xy-vsfilter is in danger of producing mismatching colors
between RGB and YUV. In all other cases, you will use the traditional render
path, which converts everything to YUV - thus a broken video renderer can not
mess up the subtitle colors alone, or cause a mismatch between sub and video
colors.Original comment by nfxjfg@googlemail.com on 29 Jun 2013 at 7:19
GoogleCodeExporter
commented
8 years ago Someone had an idea: if PlayResX/Y indicates HD (that is, BT.709 by default),
and we have "YCbCr Matrix: TV.601" or missing, then mangle the colors by
converting them to BT.601, and then back as BT.709 to RGB?
This should be a good heuristic that should catch most cases, and it could be
done entirely within libass.Original comment by nfxjfg@googlemail.com on 29 Jun 2013 at 8:27
GoogleCodeExporter
commented
8 years ago The main problem, would be a HD video which had its bitstream flagged as BT.601
or the format FourCC implies such. As far as video capture codecs are
concerned, they are often BT.601 only or BT.709 only.
The other problem, would be the occasional script you come across which has a
mismatch between PlayResX/Y and the authored video resolution. Annoying, but it
happens.
Maybe you could consider adding support something like our new subtitle
interface in Libass:
http://madshi.net/SubRenderIntf.h
Original comment by cyber.sp...@gmail.com on 30 Jun 2013 at 1:57
GoogleCodeExporter
commented
8 years ago >Maybe you could consider adding support something like our new subtitle
interface in Libass:
>http://madshi.net/SubRenderIntf.h
What about it? I don't see much interesting. Are you talking about telling
libass the video colorspace?
Anyway, since there is the danger that people think a YUV subtitle rendering
path is an absolute requirement to handle this, I made a patch for mpv, see
braindead_vsfilter_compat branch.Original comment by nfxjfg@googlemail.com on 30 Jun 2013 at 4:52
GoogleCodeExporter
commented
8 years ago > Are you talking about telling libass the video colorspace?
Yes, since that would be the only way this could be handled reliably within
libass with RGB subtitle rendering because of the above-mentioned issues.
Otherwise the video renderer would need to handle it.
> Anyway, since there is the danger that people think a
> YUV subtitle rendering path is an absolute requirement to handle this,
Correct, using a YUV subtitle path is no way an absolute requirement.
Even SubRenderIntf.h which was created around support for this header also
requires RGB subtitles.
> I made a patch for mpv, see braindead_vsfilter_compat branch.
I did a few quick tests and it seems to work as expected.
mpv win32 build + config file attached if anybody on Windows wants to test this.Original comment by cyber.sp...@gmail.com on 30 Jun 2013 at 7:56
Attachments:
GoogleCodeExporter
commented
8 years ago >Yes, since that would be the only way this could be handled reliably within
libass with RGB subtitle rendering because of the above-mentioned issues.
Otherwise the video renderer would need to handle it.
I(probably) wouldn't mind if someone writes patch. I don't know about Greg
though.
By the way I think this should be intentionally crippled, so that only the
currently used cases and "None" work. Maybe this would help keeping people away
from making full use of this header.Original comment by nfxjfg@googlemail.com on 30 Jun 2013 at 11:29
GoogleCodeExporter
commented
8 years ago > By the way I think this should be intentionally crippled, so that only
> the currently used cases and "None" work. Maybe this would help keeping
> people away from making full use of this header.
What do you consider as "currently used cases" & "making full use of this
header" ?
xy-VSFilter for its part, primarily outputs subtitles on YCbCr video,
completely oblivious to the video matrix. madshi for his part, has insisted
that madVR always produce identical output to xy-VSFilter when using the new
SubRenderIntf interface with XySubFilter. I don't see any easy way to cripple
support of the header with xy-VSFilter without also breaking the "None" cases.
As long as you at least support TV.601 script -> TV.709 (an other) video for
legacy purposes, I'm all for any other attempts to discourage idiotic use of
the header to produce mangled RGB colors. Aegisub for its part, doesn't allow
forcing anything but BT.601 in the first place. Every script Aegisub produces
with YCbCr Matrix explicitly tagged with a matrix other than TV.601, should
_always_ be untouched RGB.
I feel that you could safely restrict your implementation of the YCbCr Matrix
header to scripts which Aegisub could produce, considering its tagging behavior
is our reference implementation for proper use of the new header anyway. Once
xy-VSFilter has gained enough user-base compared to legacy VSFilter, the plan
was to change the Aegisub default so it no longer forces BT.601, at which point
all scripts would be then untouched RGB. Though when exactly this change in
defaults occurs, will ultimately be decided by the Aegisub developers, rather
than us.
That said, it would be still useful for MPV to at least support full use of the
header with vf_sub, considering correct colors when hardsubbing YCbCr video for
encoding is still an important use-case to have a matrix override available.Original comment by cyber.sp...@gmail.com on 1 Jul 2013 at 12:47
GoogleCodeExporter
commented
8 years ago If I may add my 2 cents here:
From my experience the biggest amount of ASS scripts comes from Anime content,
and there often the subtitles are *carefully* color matched to the video. My
personal goal is to create software that produces the best possible output for
end users. Obviously for such color matched ASS subtitles the best possible
output is to make sure that the color matching is maintained under all
circumstances.
Before we added the "YCbCr Matrix" header field, most ASS subtitles were
written for a fixed BT.601 matrix. But Aebisub was just starting to support
other matrixes, too, IIRC, and the libAss developers at that point had pretty
much refused to implement a "hack" to render old ASS subtitle files color
matched with BT.709 videos. So we felt we had to do something to avoid the
situation where new ASS subtitles might be incompatible with old ASS subtitles,
which would have created a BIG unsolvable mess (and it was about to happen!).
And we also tried to find a solution libAss developers might be willing to
support, which would also include support for old "broken" BT.601 ASS subtitle
files.
Many solutions were in discussion. But whatever we discussed, we found
disadvantages. After a looong fight we finally agreed on the "YCbCr Matrix"
header field. I think nobody was perfectly happy with it, but we all wanted to
finally get done with it and move on. I'm aware of that the "YCbCr Matrix"
field does have its own share of disadvantages, and probably it's more
complicated than necessary. But every other solution we discussed had
disadvantages, too.
Maybe we could have found a better solution, but it is what it is now, and from
what I've seen, the major players in the ASS subtitle market are supporting it,
so there really isn't much use in complaining about it...
After all is said and done, the "YCbCr Matrix" header field just is an
additional information field which *can* be used by the subtitle/video
renderers to perfectly match subtitle colors to the video in most situations.
You can also choose to simply ignore it, if perfectly color matched subtitles
are not important to you.Original comment by mad...@gmail.com on 3 Jul 2013 at 7:22
GoogleCodeExporter
commented
8 years ago I know, the damage is done. Just one question: why did you not restrict the
valid choices for the "YCbCr Matrix" header to "None"? Abscence of the header
would have meant BT.601-mangled.Original comment by nfxjfg@googlemail.com on 3 Jul 2013 at 8:33
GoogleCodeExporter
commented
8 years ago That was one of the options we considered, and which I did like (I think it was
even the first suggestion I made when we originally discussed the new header
field). But this solution does have disadvantages, too. Let me mention one
example:
Imagine a h264 file which in the video bitstream claims to use the BT.2020
matrix. But the container says it's actually BT.601. And the resolution is
1920x1080 which suggests BT.709. So there are 3 possible matrixes that a video
renderer could use for the YCbCr -> RGB conversion. Nobody can know for sure
which is the correct one. So every video player/renderer might make a different
decision. In this situation using "YCbCr Matrix = None" results in a 1:3 chance
to get color matched subtitles.
Yes, I know, the above case is a fringe case. But there are more common cases.
E.g. the video bitstream referencing a matrix that doesn't match the matrix you
would guess by looking at the video resolution. Or the video bitstream not
referencing any matrix and all and the video resolution being "weird" (neither
clearly SD nor clearly HD). In all such cases there's a potential for different
video renderers/players to use a different matrix, resulting in getting
subtitles which are not properly color matched to the video.
The current solution avoids these problems because the ASS file clearly
references the matrix that was used by the subtitle author. That totally takes
the matrix guessing problem out of the equation. Yes, it comes at the heavy
price of added complexity and weird color correction math. But I hope you can
see that we did put some thought into this, and didn't just try to screw up
things even more than they already were before. It's really hard to come up
with a good solution if every solution has its own problems...Original comment by mad...@gmail.com on 3 Jul 2013 at 8:48
GoogleCodeExporter
commented
8 years ago There's this argument again - even if the video is displayed incorrectly (wrong
colorspace), it's supposedly better if at least the subtitle colors match the
video correctly.
I don't really understand this kind of thinking - well, I do, but I'd rather
make sure the _video_ is displayed correctly instead. You can also allow the
user to override the video colorspace manually to fix the video.
Besides, this stuff pretty much matters for softsubbed anime fansubs only.
These always use Matroska, which doesn't even have a container colorspace.
(There's a ColourSpace field, but that's the FourCC for raw video AFAIK.) It
also appears to be a relatively homogenous community (see how use of 10 bit
h264 was introduced), so maybe they could just make sure to always tag the
colorspace correctly.
(If you ask me, they should just give up on their CPU crushing ASS typesetting,
and overlay a secondary video stream instead...)Original comment by nfxjfg@googlemail.com on 3 Jul 2013 at 9:06
GoogleCodeExporter
commented
8 years ago > even if the video is displayed incorrectly
> (wrong colorspace)
> I'd rather make sure the _video_ is displayed correctly
What happens if "correct" and "wrong" are a matter of interpretation? It's not
always 100% clear which matrix is the "correct" one.
*Yes*, I would most definitely prefer if every video had a clearly defined
matrix written to the video bitstream, and if that actually always matched the
correct matrix, and if every decoder forwarded that info properly to the video
renderer, and if every video renderer properly made use of that information etc
etc. If all that were always true, I think we would have ended up with "None"
as the only option. But we felt that we had to take into account that in
reality with certain video files different media players might sometimes end up
using different matrixes, for whatever reason.
The "YCbCr Matrix" header field simply tells us which matrix Aegisub used
during subtitle authoring. If you define the header field like that, it's not
really all that weird, is it? But yes, the resulting math required to do color
correction based on this header field is weird, I'll give you that. But I think
it's strictly an implementation problem, and not too hard to solve. The final
end user experience is what counts most, no?Original comment by mad...@gmail.com on 3 Jul 2013 at 9:37
GoogleCodeExporter
commented
8 years ago >and if every decoder forwarded that info properly to the video renderer, and
if every video renderer properly made use of that information etc etc.
But now you have to make sure that the subtitle renderer passes the information
correctly to the video renderer (with that new xy-madvr subtitle interface).
And I really don't think it's the task of a subtitle format to account for
random issues with random dshow components.
>The "YCbCr Matrix" header field simply tells us which matrix Aegisub used
during subtitle authoring. If you define the header field like that, it's not
really all that weird, is it?
Yeah, if Aegisub emulates a blatantly incorrect and broken video decoder. It
adds to your point, I'll give you that.
>But I think it's strictly an implementation problem, and not too hard to solve.
No, it's not hard to solve. But now your subtitle format dependent on the
video. Kind of reminds me of frame-timed subtitle formats, which fortunately
nobody uses anymore.Original comment by nfxjfg@googlemail.com on 3 Jul 2013 at 9:58
GoogleCodeExporter
commented
8 years ago > now your subtitle format dependent on the video.
Yes, but isn't that the very nature of color matched subtitles?
I do get your point, though. I guess the one thing where our opinion differs
the most is that I'm aiming for the best end user experience, and I'm willing
to live with a weird spec and implementation in return. While you prefer to
have a clear and simple spec and implementation and you can live with a few
rare compatability issues instead.Original comment by mad...@gmail.com on 3 Jul 2013 at 10:15
GoogleCodeExporter
commented
8 years ago >I guess the one thing where our opinion differs the most is that I'm aiming
for the best end user experience
No. You're adding weird corner cases to a format already full of weird corner
cases. It will get worse for the user instead of better, becauseall these weird
corner cases multiply the number of things that could go wrong. This happens
all the time in the real world and it's a good reason to reject hacks such as
this one. Format extensions which affect other aspects instead of just fixing
the broken case are especially bad, and this applies to this one too.Original comment by nfxjfg@googlemail.com on 3 Jul 2013 at 10:44
GoogleCodeExporter
commented
8 years ago I disagree. The combination of XySubFilter and madVR should produce color
matched subtitles in pretty much every case, including all those funny corner
cases. So it should all be good for the end user, at least when using
XySubFilter and madVR. Of course I can't vouch for other software. But if
everyone starts supporting "YCbCr Matrix" then end users should have the same
positive experience with other software, too.Original comment by mad...@gmail.com on 3 Jul 2013 at 10:50
GoogleCodeExporter
commented
8 years ago >The combination of XySubFilter and madVR
> I can't vouch for other software
Just some posts above you said this is needed because not every software does
it right. (I see your point, but I still found this funny.)Original comment by nfxjfg@googlemail.com on 3 Jul 2013 at 10:56
GoogleCodeExporter
commented
8 years ago > Just some posts above you said this is needed
> because not every software does it right.
But that's not really a fair summary of what I said. My key point was not that
some software does things wrong. My key point always was that sometimes things
are open for interpretation. That's quite a different thing. Even if every
software does everything correctly, it's still possible that different software
might use different matrixes, because sometimes you can only *guess* which is
the correct matrix, and different software might use different guessing
algorithms/priorities.
Fact is that the "YCbCr Matrix" header field allows every software which uses
it to produce color matched subtitles. It takes guessing out of the equation.
If "None" were the only option, even perfectly correct software could produce
non-matching colors in some corner cases.
So for *properly written software*, the end user experience with "YCbCr Matrix"
is very good, better than it would have been with "None" as the only option, I
believe. For badly written software all bets are off, anyway...Original comment by mad...@gmail.com on 3 Jul 2013 at 11:17
GoogleCodeExporter
commented
8 years ago And my point was: tag the colorspace correctlym and you're done.
By the way, nobody cared about breaking libass with HD video all this time. ISR
probably too, though I'm not sure how exactly it works. Possibly
vsfilter-on-RGB as well, if that ever worked. Compatibility? Bullshit.Original comment by nfxjfg@googlemail.com on 3 Jul 2013 at 11:41
GoogleCodeExporter
commented
8 years ago > nobody cared about breaking libass with
> HD video all this time
Not sure what you mean. As far as I understand, libass had non-matching
subtitle colors all along with HD video. Not sure what "YCbCr Matrix" has to do
with that?Original comment by mad...@gmail.com on 3 Jul 2013 at 12:22
GoogleCodeExporter
commented
8 years ago >Not sure what you mean. As far as I understand, libass had non-matching
subtitle colors all along with HD video. Not sure what "YCbCr Matrix" has to do
with that?
Yes, "all along". As in, when they switched to HD video, they didn't care that
the colors were suddenly "wrong" on libass. (The colors were wrong on vsfilter
of course, but it was just accepted, and no mind was payed to libass.)
"They" is the anime fansub scene. They don't care about compatibility, only
whether it works with their familiar selection of dshow components. They don't
give a shit about anything outside, but when it comes to things they care about
they seem to go enormous lengths to ensure compatibility.Original comment by nfxjfg@googlemail.com on 3 Jul 2013 at 12:27
GoogleCodeExporter
commented
8 years ago > As in, when they switched to HD video, they didn't care that the colors were
> suddenly "wrong" on libass. (The colors were wrong on vsfilter of course, but
> it was just accepted, and no mind was payed to libass.)
Where did you get that idea? The fansub scene definitively cared (I was a
fansubber in a major group back when HD fansubs were first emerging). The
problem was that no developers seemed to care, so everybody just stuck with
what worked, since Libass was breaking scripts left and right and had literally
zero user-base on Windows. Libass bug-for-bug compatibility with VSFilter
during that period was extremely poor, which caused bigger issues than just
that of a incorrect color matrix for existing scripts. Not to mention that
VSFilter had been a dead project for years by the time HD video emerged, with
no developer, and everybody scared to touch the code for fear of breaking
something.
Why did Libass developers leave this situation as it was for years, rather than
spend a few hours to figure out how to add BT.709 support to VSFilter, or at
least make a push to garner more support on Windows in a similar fashion to
that we are now doing with xy-VSFilter? Lost opportunity IMHO. As far as I
could tell, _Nobody_ cared. Everybody was just turning a blind eye to this
BT.601 only issue with VSFilter, possibly hoping VSFilter would just die. This
made the situation with existing scripts so bad when xy-VSFilter finally came
around added BT.709 support, we had little choice but to support those BT.601
only scripts, and attempt to displace legacy VSFilter marketshare to the point
where hopefully people would feel comfortable enough to start using the correct
matrix compatible with Libass and even VSFilter RGB output.
We have been attempting to fix stupidity in VSFilter, but there is a limit to
how much we can safely change with xy-VSFilter. The main selling point of
xy-VSFilter which resulted in us gaining such a large user base so quickly, is
VSFilter-compatibility with enhanced performance. There is a fine line between
things we can fix and be accepted broadly, and those which break VSFilter
compatibility entirely. We don't want to end up in the same situation as
Libass, and cause everybody to migrate back to legacy VSFilter again when their
existing scripts stop rendering correctly...
Just know that we at xy-VSFilter have good intentions and desire compatibility
with Libass where possible, but also see maintaining legacy VSFilter
compatibility the necessary evil which allows us to sneak in minor improvements
and bug fixes every once in awhile. I'm am just happy that we have been
starting to have these discussions about unifying rendering behavior between
Libass and xy-VSFilter at all.Original comment by cyber.sp...@gmail.com on 3 Jul 2013 at 6:01
GoogleCodeExporter
commented
8 years ago >and everybody scared to touch the code for fear of breaking something.
This is true. Last time someone hacked vsfilter (like adding the \blur tag) the
result was a buggy dependency on video resolution, and a performance hazard.
(Hey, let's blur extremely large glyphs!) So, in some ways, it would have been
better if nobody had touched it at all.
>Why did Libass developers leave this situation as it was for years, rather
than spend a few hours to figure out how to add BT.709 support to VSFilter,
Heh, so nobody dared to touch vsfilter, but somehow it's the libass devs
failure to do so anyway?
The libass developers put a lot of work into this library. Eugeni Stepanov
wrote the original code, back then integral part of MPlayer. Then he lost
interest, and Greg picked it up. He made libass a standalone library, and
probably fixed hundreds of bugs and issues. He even went as far as adding
proper support for international text and trying to make it independent of
fontconfig. And after all this work, libass performs pretty well. I guess
making a big issue out of all these small nagging vsfilter fringe cases is a
bit tiring in the end. (I myself started contributing not even a year ago, btw.)
> or at least make a push to garner more support on Windows in a similar
fashion to that we are now doing with xy-VSFilter? Lost opportunity IMHO.
Windows is not exactly libass' home territory. In fact, libass was created
_because_ vsfilter was absolutely not available on Linux. It was open source,
but the code was highly windows specific and had deep depdendencies on the
windows API. I imagine some people were advocating using libass on windows, but
three major obstacles held it back: 1. fontconfig, 2. lack of dshow filter (you
expect these Linux programmers to deal with dshow?), 3. bug for bug
compatibility with vsfilter. All of these are pretty big ones, maybe with the
lack of a dshow filter the biggest one, because it didn't even allow for
experimentation.
Anyway... I don't really want to whine about how libass has be neglected (at
least not right now), I was just making a point that perfect compatibility is
an illusion. There are still scripts produced that happen to perform fine on
xy-vsfilter but exhibit very bad performance in libass. Even easily avoidable
breakages are common. And my main problem with the issue at hand makes the
_format_ much worse, _including_ new scripts. The most obvious problem is that
it requires non-trivial changes to users of the libass library, instead of
libass itself. I've repeated this many times. This discussion is pretty
pointless now.
>We don't want to end up in the same situation as Libass, and cause everybody
to migrate back to legacy VSFilter again when their existing scripts stop
rendering correctly...
vsfilter is the only choice on windows, libass is the only choice elsewhere.
That's how it's always been.
Original comment by nfxjfg@googlemail.com on 4 Jul 2013 at 11:56
GoogleCodeExporter
commented
8 years ago New patch. Compared to the previous one, adjust explanation of "None". Also
move the enum definition out of the struct definition. @chortos: is this ok?
I also wonder how this stuff is supposed to work should libass ever decide to
output RGBA bitmaps instead of A8 ones.Original comment by nfxjfg@googlemail.com on 4 Jul 2013 at 12:08
Attachments:
GoogleCodeExporter
commented
8 years ago > Heh, so nobody dared to touch vsfilter, but somehow it's
> the libass devs failure to do so anyway?
I was more implying that leaving VSFilter broken with BT.601 only for an entire
decade hurt Libass and the ASS specification more than anything. But what can
you do, this is all hindsight observations now, the damage has been done and
now were stuck supporting borked BT.601 scripts indefinitely. All we can do
now, is attempt to migrate people into proper behavior.
This comes back to how we could really use a successor specification to ASS,
where everything can be defined sane and logical from the very start...
> three major obstacles held it back
The fourth was ffmpeg swscale behavior/performance/quality via MPlayer and
derivatives. If there wasn't going to be a directshow filter, the next best
thing would have been fixing up MPlayer + GUI to be comparable/superior to a
directshow filter chain. For quite a long time, MPlayer couldn't even use
BT.709 matrix on HD video automatically. This was something you finally fixed
on your shader renderers from what I remember.
> There are still scripts produced that happen to perform fine on xy-vsfilter
but exhibit very bad performance in libass.
FWIW, the opposite is true as well. Extremely complex font outlines with 3D
movement can kill VSFilter performance, while running flawlessly in Libass.
>> cause everybody to migrate back to legacy VSFilter again when their existing
scripts stop rendering correctly...
> vsfilter is the only choice on windows, libass is the only choice elsewhere.
That's how it's always been.
What I meant by this is we don't want to see people migrate back to VSFilter
from xy-VSFilter because of a change which broke compatibility horribly. This
is why we've been very careful in regard to changes we've made up to this point.
> Compared to the previous one, adjust explanation of "None".
You could also mention that Aegisub scripts which are explicitly tagged with a
matrix other than "TV.601" are expected to be untouched RGB, similar to "None".
> I also wonder how this stuff is supposed to work should libass ever decide to
output RGBA bitmaps instead of A8 ones.
The same way we do it with XySubFilter + madVR? Our subtitle interface uses
RGBA bitmaps w/ pre-multipled alpha. Maybe I'm missing the problem for Libass?Original comment by cyber.sp...@gmail.com on 4 Jul 2013 at 7:00
GoogleCodeExporter
commented
8 years ago I'm quite happy with the new patch.
I'm also even more happy to see cyberbeing and madshi join the discussion, and
just generally to see the discussion return to being more civil. :) Thanks!Original comment by chortos@inbox.lv on 4 Jul 2013 at 9:16
GoogleCodeExporter
commented
8 years ago > This comes back to how we could really use a successor specification to ASS,
where everything can be defined sane and logical from the very start...
Yeah, this is a topic all the time.
> FWIW, the opposite is true as well. Extremely complex font outlines with 3D
movement can kill VSFilter performance, while running flawlessly in Libass.
IMO this whole idea treating ASS like a vector format and doing complex
typesetting with it is an aberration. The fact that the user's hardware (and
playback software) has a higher influence on smooth "subtitle" rendering than
on video decoding and playback is indicator for that.
> You could also mention that Aegisub scripts which are explicitly tagged with
a matrix other than "TV.601" are expected to be untouched RGB, similar to
"None".
Is that so? That's a really big difference.
>> I also wonder how this stuff is supposed to work should libass ever decide
to output RGBA bitmaps instead of A8 ones.
> The same way we do it with XySubFilter + madVR? Our subtitle interface uses
RGBA bitmaps w/ pre-multipled alpha. Maybe I'm missing the problem for Libass?
As far as I'm aware your interface includes vsfilter color mangling too. If
libass outputs RGBA bitmaps at one point, the video output would require such
an interface as well. But usually they don't have the capability for this
(consider vdpau), and I'm pretty sure I don't want to add complexity to the
video outputs anyway.
So maybe libass should have an API function to set the video colorspace, to
allow it to mangle the colors internally. You'd have to make sure that libass
and the player's video YUV->RGB conversion agree on the same matrix, as well as
making it robust enough so that obscure or unexpected colorspaces don't just
break it.
But I don't know whether libass will ever output RGBA, and I prefer not to
think about it.Original comment by nfxjfg@googlemail.com on 5 Jul 2013 at 12:02
Original issue reported on code.google.com by
nfxjfg@googlemail.comon 28 Jun 2013 at 6:39