Unifying rendering across resolutions (xy-VSFilter scale function discussion and feedback)

[GoogleCodeExporter]

Okay, so this is somewhat related to the VSFilterForMadVR, but I figured this 
would be better as a separate issue. Basically, if our goal is to render 
subtitles at native desktop resolution (like ISR does), then we need to do some 
changes to certain features like 3D rotation so that no typesetting gets broken 
from the resolution differences. I gave some thought to this and came up with 
the following:

Basically, xy-VSFilter needs to take the script resolution more into account. 
All 3D rotation calculations are made at script resolution, and then "scaled" 
to the rendering resolution. This should be done for both the normal YCbCr 
rendering as well as RGB rendering over the new interface. So basically it 
would mean the following:

1. 3D rotation would still be different at different script resolutions 
(whereas now they are different as long as the rendering resolution is 
different)
2. 3D rotations would be identical across different rendering resolutions as 
long as the script resolution is the same
3. This would mean that if you have a 1280x720 script typeset to 1280x720 video 
with 3D rotations, you could re-use the same script for 1080p, 720p and 480p 
encodes of the same content and the rotations would look identical everywhere 
(this is not currently the case)

With this kind of approach, we would obtain the highest level of backwards 
compatibility - all old scripts that were typeset with script resolution 
identical to the video resolution will still work correctly. What will be 
broken is scripts that were typeset with a script resolution that doesn't match 
the video resolution and involve 3D rotations, but we should just consider 
these scripts to be faulty and ignore them. The only way to be 
backwards-compatible with even this scenario would be pretty much to introduce 
yet another ASS header, and would we really want that?

Beyond 3D rotation, there also other things that should be taken into account 
when rendering at a different resolution from video resolution. Take anamorphic 
video, for instance. If a script has been typeset to 720x480 and for example 
the dialogue style has X-Width of 84% to compensate for the stretching (so that 
it will look normal-width on playback at video resolution rendering), currently 
with ISR it gets rendered incorrectly with 84% width. In other words, 
xy-vsfilter should probably do aspect ratio compensation by default, at least 
with ASS subtitles.

Going back to typesetting, one more thing that comes to my mind is the \be and 
\blur tags - most typesetters use a varying amount of blur for signs in order 
to match them up accurately with the video, so if you suddenly have the script 
rendered at a much higher resolution, these same blur values won't match up 
anymore. As such, in my opinion \be and \blur should also be scaled according 
to script resolution and rendering resolution. Demonstration here: 
http://screenshotcomparison.com/comparison/124672

I don't think this would need anything more complex than simple multiplication 
based on the resolution difference, so if for example a 1280x720 is rendered at 
1920x1080, all the blur values get multiplied by 1.5 (1080/720). Here's what it 
would look like for the comparison linked above: 
http://screenshotcomparison.com/comparison/124673

As you can see, it may not be a "perfect" match for all the elements, but on 
the other hand different scaling algorithms can cause difference in end-product 
sharpness (the comparisons above use Spline 4-tap for both luma & chroma), so I 
think we should just use a simple approach and leave it at that - it will still 
look a lot better than not compensating at all.

Anyway, I guess that's about it for what comes to my mind about this. Thoughts?

Original issue reported on code.google.com by Daiz...@gmail.com on 13 May 2012 at 4:12

[GoogleCodeExporter]

Thank you for consolidating your thoughts Daiz.

The challenges with 3D rotation, Script Resolution, Output Resolution, Aspect 
Ratio and \blur + \be were actually all things I brought up early in the 
original Issue #40 discussions, and were taken into consideration when 
designing our initial version 1.0.0 of the new interface 
http://madshi.net/SubRenderIntf.h

> What will be broken is scripts that were typeset with a script resolution
> that doesn't match the video resolution and involve 3D rotations, but we
> should just consider these scripts to be faulty and ignore them. The only
> way to be backwards-compatible with even this scenario would be pretty much
> to introduce yet another ASS header, and would we really want that?

No need for another ASS header, these issues will be solved by information 
communicated over the new interface, with the goal zero broken scripts and 100% 
backwards compatibility.

The plan was to be smart about it and leave no scripts broken by calculating 
corrections based on a combination of script resolution, video resolution, 
output resolution, and aspect ratio as well as compensating blur, all done 
dynamically. YuZhuoHuang is up for the challenge of implementing these dynamic 
corrections within xy-VSFilter for use over the new interface, and didn't 
foresee any problems.

At this point, what would be most helpful is forming a collection of accurately 
typeset VSFilter script+video samples of various combinations of 3D rotations, 
script resolution matches/mismatches, and corrected/non-corrected aspect ratios 
to use for regression testing on the new interface once implementation begins. 

If anybody would like to assist with this, please create a Windows SkyDrive 
account (as one of few international file lockers YuZhuoHuang can access within 
China), and EMAIL me a link to a shared folder which you've uploaded samples. 
Please trim samples as small as possible around the sections with typesetting. 
Basically, if a video has 30 seconds worth of typesetting split over say 5 
sections over the course of the video, upload each of these sections 
individually; don't upload an entire 24+ minute episode and waste YuZhuoHuang's 
bandwidth.

Original comment by cyber.sp...@gmail.com on 13 May 2012 at 8:09

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

regarding the scaling of \be and \blur tags, 
http://code.google.com/p/libass/issues/detail?id=6 might be interesting.
Also, the \be tag only accepts integer values, can it be scaled accurately at 
all?

Original comment by TheDarkS...@googlemail.com on 16 May 2012 at 8:07

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Thanks for the explanation. Also, after taking a closer look at the example in 
the libass Issue, I think it may be related to how blurring is done (or rather, 
how I think it is done):
When there's (however small) of a border, only the border is blurred, and the 
primary text is left completely unaffected. However, when there's no border at 
all, the primary text is blurred instead, and it might be possible that only 
for this case, the \blur value must not be scaled. However, this might just as 
well be complete nonsense, so feel free to delete this post if it turns out to 
be useless.

Original comment by TheDarkS...@googlemail.com on 18 May 2012 at 2:27

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I just realized my previous Comment #4 didn't make any sense, since I forgot to 
scale the border when doing my brief testing the other day. So yes, that could 
mean that \be, unlike \blur, may not be able to be scaled perfectly unless 
YuZhuoHuang finds a creative way to do so.

The libass issue is something completely different. It occurs because libass 
scales border+shadow+blur from the 'script playres'->'output resolution', while 
vsfilter only scales border+shadow from 'script playres'->'video resolution'.

To match vsfilter behavior, libass would need to only scale border+shadow 
'script playres'->'video resolution' and then border+shadow+blur 'video 
resolution'->'output resolution'.

Original comment by cyber.sp...@gmail.com on 18 May 2012 at 4:32

[GoogleCodeExporter]

Original comment by cyber.sp...@gmail.com on 25 Aug 2012 at 12:31

• Changed title: Unifying rendering across resolutions (xy-VSFilter scale function discussion and feedback)

[GoogleCodeExporter]

It will be a bit longer until I post the first build for testing.

YuZhuoHuang just added an experimental floating-point implementation of \be 
which should enable it to be scaled, but it still needs to be tweaked a bit.

Original comment by cyber.sp...@gmail.com on 28 Aug 2012 at 5:39

[GoogleCodeExporter]

I apologize for the delay. Perfect scaling of \be doesn't seem possible, so the 
current \be scaling implementation is a median compromise which favors 
maintaining 'energy' (lightness, transparency) over optimal blurriness. The 
problem is the appearance of VSFilter's \be implementation with large number of 
iterations is based entirely on rounding error... This rounding error cannot be 
scaled in any practical way, so however \be scaling is implemented in 
xy-VSFilter will be a compromise of some sort. Other notable \be changes are 
we've 'fixed' the VSFilter 2.39/2.41 bounding box issue which sometimes caused 
the edges of \be blur to get cropped of, and for testing purposes, \be will 
accept floating point values in the script. Feedback welcome.

Attached is the xy-VSFilter Scale Test Build 1.
Required: FFDShow or some other decoder which contains a resize filter

On xy-VSFilter's About tab, you'll find "Renderer Layout Options".

Use Original Video Size = Input video frame is used for layout (VSFilter 2.39 
Default Behavior, no scaling)

Customize = Customized layout resolution (Will be used in testing the scale 
function)

In order achieve correct scaling, Customize must be set to the video resolution 
which the script was originally authored for. Assuming original embedded 
subtitles, set customize to the resolution of the video. For anamorphic video, 
set Customize to the pre AR-corrected video size (i.e. 720x480 NTSC DVD) if 
your script was pre compensated, or set Customize to the post AR-corrected 
video size (i.e. 853x480 16:9 NTSC DVD) if your script was _not_ pre 
compensated. Eventually with the new subtitle interface, this entire process 
will be automated as much as possible.

Example workflows for subtitles at 2560x1440 desktop resolution.

1)
Video Resolution 1280x720 
xy-VSFilter Customize 1280x720
FFDshow Resize 2560x1440

2)
Video Resolution 1920x1080 
xy-VSFilter Customize 1920x1080
FFDshow Resize 2560x1440

3)
Video Resolution 720x480 (16:9 Anamorphic, Script pre compensated for VSFilter)
xy-VSFilter Customize 720x480
FFDshow Resize 2560x1440

4)
Video Resolution 720x480 (16:9 Anamorphic, Script _not_ pre compensated for 
VSFilter)
xy-VSFilter Customize 853x480
FFDshow Resize 2560x1440

Note: VSFilter's PAR Compensation function is not compatible with the Scale 
function. Please set it to its default state 'Disable' when testing xy-VSFilter 
scaling. The PAR Compensation function is essentially depreciated, as you'll 
get superior results using the Scale function.

Special case for dual-releases. For example, a script designed for a 1280x720 
video, which was embedded as-is into a 1920x1080 video without corrections
Video Resolution 1920x1080
xy-VSFilter Customize 1280x720
FFDshow Resize 2560x1440

Rule of thumb: Set xy-VSFilter Customize to the resolution of the video frame 
the script was originally authored to in Aegisub. Do not confuse this with the 
PlayRes value tagged in the script. VSFilter performs layout as a function of 
PlayRes and Video Resolution. Customize is an override of Video Resolution, not 
PlayRes. You should always assume the resolution of the video which a script 
was originally embedded/paired with is the correct value for Customize, not 
PlayRes.

Please limit all feedback and bug reports about xy-VSFilter scaling to the 
comments here at Issue #97. All 3D transforms and ASS tags (except \be to a 
minor extent) should have identical placement and appearance when scaled, aside 
from being rendered in higher resolution. If you find anything which looks 
different when subtitles are scaled by xy-VSFilter, please attach an example 
script with steps to reproduce, and screenshots of the problem if applicable.

Original comment by cyber.sp...@gmail.com on 10 Sep 2012 at 11:07

Attachments:

• xy-VSFilter_Scale_Test_Build_1.7z

[GoogleCodeExporter]

> On xy-VSFilter's About tab, you'll find "Renderer Layout Options".

On xy-VSFilter's _More_ tab, you'll find "Renderer Layout Options".

Original comment by cyber.sp...@gmail.com on 10 Sep 2012 at 11:24

[GoogleCodeExporter]

@cyber
you say \be have some problems, but what internal MPC renderer does in this 
situation? It can render subs at any resolution. I never actually compared 
them, but to me its version of \be looks similar.

Original comment by yakits...@gmail.com on 17 Sep 2012 at 9:10

[GoogleCodeExporter]

The MPC internal renderer doesn't scale \be at all, and neither does Libass or 
Aegisub's script resampling function.

xy-VSFilter Scale Test Build 1 scales \be by be_strength*scale_factor. Since 
be_strength is number of iterations, and iterations can only be integer, an 
algorithm is used to generate floating point be_strength between adjacent 
iterations.

For example:
1280x720 -> 1920x1080 is a scale factor of 1.5
If the script contains \be3 @1280x720, xy-VSFilter would use \be4.5 @1920x1080
\be4.5 would have blurriness halfway between \be4 & \be5

For maintaining the blurriness of \be, using 
be_strength*scale_factor*scale_factor was a better approximation from our 
testing, but runs into major energy issues once you get into upscaling \be20 or 
higher range because of the extreme rounding error in the original VSFilter \be 
implementation.
For example:
1280x720 -> 1920x1080 scale factor of 1.5*1.5 = 2.25
If the script contains \be3 @1280x720, optimal blurriness would be close to 
\be6.75 @1920x1080, which isn't an issue.
Yet if the script contains \be30 @1280x720, optimal blurriness would be close 
to \be67.5 @1920x1080 which has an end result much more faded and light than 
the original because of the large rounding error from \be67 & \be68 which 
exists in the VSFilter 2.39 variable strength \be implementation with high 
be_strength...yet almost non-existent rounding error at low be_strength.

Eliminating the rounding error doesn't work well, since it makes the end result 
something like >10x darker than VSFilter 2.39 at high be_strength.

Attempting to scale the VSFilter 2.39 rounding error with simple math didn't 
work well either, resulting in various undesired anomalies to blurriness and 
energy, not to mention that attempting to scale a rounding error is an 
extremely dirty hack to begin with...

That brought us back to releasing xy-VSFilter_Scale_Test_Build_1 using a simple 
be_strength*scale_factor, which as described above was a median compromise 
between blurriness and energy/lightness across the entire be_strength range.

Depending on xy-VSFilter_Scale_Test_Build_1 feedback about \be, I had one 
additional idea we haven't tried yet of using a stepped progression to optimize 
blurriness scaling at low be_strength, while minimizing energy problems at the 
expense of blurriness as be_strength increased. Something as follows. Though as 
you can gather, this would have it's own advantages/disadvantages VS. the 
simple be_strength*scale_factor in xy-VSFilter_Scale_Test_Build_1, and would be 
yet another comprise solution:
be_strength*scale_factor*scale_factor (low be_strength after scaling)
be_strength*scale_factor (medium be_strength after scaling)
be_strength*scale_factor*sqrt (high be_strength after scaling)

The VSFilter 2.39 variable strength \be implementation is inherently flawed @ 
high be_strength, and was never intended to allow scaling considering it was 
based on number of integer iterations. Unfortunately the VSFilter 2.39 \be 
implementation is something we are all stuck with now, as people have been 
using it for years. 

Does everybody find the be_strength*scale_factor implementation from 
xy-VSFilter_Scale_Test_Build_1 to be acceptable, and the best compromise for 
scaling \be? Remember that xy-VSFilter_Scale_Test_Build_1 will accept floating 
point values in the script, so you can play around with different floating 
point \be values with scaling disabled (Use Original Video).

If anybody disagrees that be_strength*scale_factor is the best compromise for 
\be scaling, please provide us with an alternative method which you believe 
would work better. Keep in mind the following. Matching the look of VSFilter @ 
identical be_strength and rendering resolution is easy, but matching the look 
of high resolution subtitles + higher be_strength to low resolution subtitles + 
lower be_strength is hard because of the unpredictability in VSFilter 2.39 \be 
rounding error.

Original comment by cyber.sp...@gmail.com on 18 Sep 2012 at 1:36

[GoogleCodeExporter]

Just an idea. Why not use an alternative blur algorithm that accepts radius and 
intensity as parameters. Instead of scaling the intensity, just scale the 
radius instead.

Original comment by ratei.th...@gmail.com on 8 Oct 2012 at 11:19

[GoogleCodeExporter]

Not a good idea, since using an alternative algorithm would change the 
appearance of the \be blur effect. The \blur tag is already available for 
people who want a radius based Gaussian Blur, and it should scale perfectly.

In a better world, when variable strength \be support was hacked\patched into 
VSFilter years ago, a maximum limit no greater than 10 would have been set to 
minimize error and discourage it's use over \blur for any significant blurring. 
Unfortunately that wasn't the case, so we're stuck with compromise solutions 
that need to maintain VSFilter's unpredictable look resulting from the rounding 
error at high values, while not messing up low values which have nearly 
non-existent error.

Original comment by cyber.sp...@gmail.com on 9 Oct 2012 at 1:58

[GoogleCodeExporter]

To clear up some confusion I've seen online, xy-VSFilter_Scale_Test_Build_1 
DOES NOT use the new subtitle interface which was added in the latest madVR 
builds. Subtitles in Scale_Test_Build_1 are still rendered at video resolution, 
with the intention of testing the core subtitle scaling functionality by giving 
xy-VSFilter upscaled video as input. Making use of the scale function in this 
way is not intended for practical everyday use.

After our next "normal" xy-VSFilter stable build is released this month, we 
will begin working towards releasing a "new subtitle interface" xy-VSFilter 
build supporting the functionality added in "madVR 0.84.5+". Please note that 
most importantly, these initial madVR builds do not support BT.601 scripts on 
BT.709 video when using the new subtitle interface (colors will be incorrect). 
madshi will add support in madVR for correct subtitle colors and other 
enhancements after he has a "new subtitle interface" xy-VSFilter build for 
testing.

Original comment by cyber.sp...@gmail.com on 4 Nov 2012 at 9:27

[GoogleCodeExporter]

The functionally for xy-VSFilter_Scale_Test_Build_1 is now included in 
xy-VSFilter 3.0.0.211.

A build supporting the new subtitle interface with madVR, is still not ready at 
this time.

Original comment by cyber.sp...@gmail.com on 20 Nov 2012 at 9:45

[GoogleCodeExporter]

I did some testing with the scaling: 
http://screenshotcomparison.com/comparison/159147

I used 4-tap lanczos for scaling with ffdshow resize (for the xy-vsfilter 
scaled shot) and madVR (for the original 720p shot). Obviously it's impossible 
to get it completely perfect due to different scaling algorithms and such, but 
even so, this is looking quite good!

Original comment by Daiz...@gmail.com on 20 Nov 2012 at 11:24

[GoogleCodeExporter]

We're having a discussion about scaling font sizes in libass:
    http://code.google.com/p/libass/issues/detail?id=78
In short, \fs affects font hinting, which affects glyph appearance and spacing.

If \fs is scaled along with the rendering resolution, changes in resolution 
(such as window resizes) occasionally change hinting significantly enough to 
produce sudden jumps in text. This is noticeable, for example, when resizing a 
window with video and subtitles rendered at the window's resolution (as in 
MPC-HC ISR, mplayer with vo_gl and madVR with xy-VSFilter talking over the new 
interface).

Even when the changing hinting does not produce unpleasant jumps, it still 
means the picture produced with scaling inside the subtitle renderer is 
different from the picture produced without it and scaled by the video renderer 
or a separate filter. In other words, \fs loses resolution independence.

Besides, font systems used by both libass and xy-VSFilter seem to round 
requested font sizes to integral multiples of some units. (For FreeType this is 
pixels.) This adds glyph size jumps to the glyph form and spacing changes 
already present due to hinting. (This is also noticeable on \t(\fs), but 
exactly due to these issues nobody does that.)

My tests show that VSFilter and xy-VSFilter scale \fs when the video resolution 
differs from the script resolution. I also know that VSFilter and, by default, 
xy-VSFilter do supersampling that means \fs is increased by a factor of eight.

A related issue is that hinting for very small font sizes results in jerking on 
\t(\fscx\fscy). This is not noticeable in VSFilter and the default xy-VSFilter 
setup due to the increase in \fs produced by supersampling.

Over at libass, we have several ideas as to how this bunch of problems can be 
solved. I'll try to summarize the options, good and bad, in a list:

(1) Retain the eightfold supersampling. Keep scaling \fs with the video 
resolution, or not. Stop scaling \fs with the rendering resolution and instead 
scale \fscx\fscy.

(2) Drop hinting and grid fitting entirely, if this can be achieved using our 
font subsystems. Scaling \fs and \fscx\fscy will then have the exact same 
effects, and supersampling does not matter. Grigori seems to prefer this 
approach.

(3) Request a fixed font size from the font subsystem and adjust \fscx\fscy 
appropriately to get to the needed size in the end. This is practically 
equivalent to (2) except hackish. Additionally, as Grigori notes, the font 
subsystem still tries to do hinting, which is now just a waste of resources. 
Nevertheless, this is how the git master of libass works at the moment.

(4) Ignore the window resizing and \fs resolution independence issues. Make no 
changes in xy-VSFilter: retain the eightfold supersampling, keep scaling \fs 
with the video resolution, and keep scaling \fs with the rendering resolution. 
At first this seems to have an advantage: it kind of benefits from font 
hinting. But the hinting is done at a wrong font size due to supersampling and 
\fscx\fscy. Indeed, it is always done at a font size larger than the effective 
rendered size with today's computer screens (even watching a 240p video 
full-screen on a Retina MacBook Pro gives just a 7.5x enlargement).

(5) Ignore the window resizing and small font size jerking issues, and instead 
opt for proper font hinting. Ditch the supersampling. Keep scaling \fs with the 
video resolution. Keep scaling \fs with the rendering resolution. Make 
\fscx\fscy affect hinting in some way (first approximation: scale \fs by the 
minimum or maximum of \fscx and \fscy). Advantage: font hinting. Disadvantages: 
everything else.

The behaviour I'd want from an ideal subtitle format with an ideal renderer 
would be to discard hinting and grid fitting entirely for moving typeset signs 
and do the exact opposite (drop supersampling and aim for the best hinting) for 
regular subtitles. Perhaps even with an option for non-moving typeset signs, 
which might want to depend on exact [non-]hinting. Of course, such behaviour is 
impossible to achieve with ASS in its current form (although it is in fact 
possible to approximate with enough effort--I doubt anyone wants to put in this 
effort though).

So for libass we're currently discussing (1) and (2) as the most likely ways to 
go. I'm the one who proposed (1), but Grigori proposed (2) today and I think 
I'm starting to sway towards that too. What do you think? And would you be 
willing to alter xy-VSFilter to behave the same?

Original comment by chortos@inbox.lv on 20 Dec 2012 at 6:46

[GoogleCodeExporter]

Unfortunately, a prompt technical discussion is not possible at this time. The 
project was put on hiatus because xy-VSFilter's developer YuZhuoHuang is 
completely without internet access until mid-Janauary (~4 weeks from now).

VSFilter has always used GDI32 (resolution-dependent, whole pixel grid-fitting) 
internally. I believe eightfold supersampling is required in order to have 8x8 
sub-pixel positioning in VSFilter, so dropping supersampling wouldn't be an 
option with our present scanline converter. YuZhuoHuang has been considering 
the prospect of writing a high quality floating-point scanline converter with 
anti-alaising support for xy-VSFilter, but at this point it's nothing more than 
a nice idea & possible long term goal. 

(1) is xy-VSFilter's behavior when using the scale function.
Proper rendering as long as "Authored Video Resolution" is known.

(4) is xy-VSFilter's behavior when _not_ using the scale function, as well as 
VSFilter's default behavior.
Proper rendering only when "Authored Video Resolution" == "Rendering 
Resolution".

Beyond these brief statements, I'd like to hold off further discussions about 
potential for VSFilter behavior changes until YuZhuoHuang is able to 
participate.

Original comment by cyber.sp...@gmail.com on 21 Dec 2012 at 7:02

[GoogleCodeExporter]

Thanks for your reply.

About supersampling, I realized what I wrote wasn't very clear: I didn't mean 
dropping VSFilter's supersampling entirely, but rather stopping applying it to 
\fs specifically (instead of doing \fs{fs*8}, VSFilter could do 
\fs{fs}\fscx{fscx*8}\fscy{fscy*8}).

It's good to know that the scaling function of xy-VSFilter already does (1). I 
guess I'll be looking forward to seeing what YuZhuoHuang thinks in January and 
continue the discussion in the libass issue tracker (and possibly implement 
some sane-ish solution) in the meantime.

Original comment by chortos@inbox.lv on 21 Dec 2012 at 11:37

[GoogleCodeExporter]

so, seeing how a few months have passed since the last post on the matter, 
what's YuZhuoHuang's opinion on the Supersampling issue?  I'm just interested, 
so please don't misunderstand my reviving the issue.

On another note, a while back I was told in Issue #118 that a set of ASS Header 
flags may or may not be introduced sooner or later to tell xy-VSFilter the 
Layout Resolution to base its scale function on, so the user wouldn't need to 
set it manually during playback when it differs from the played video's 
resolution.  I'd like to start some talks about this, if it's okay (if it's not 
okay, I can open a new issue for this - I just thought that it falls pretty 
much under the description of this issue's title).

Original comment by TheDarkS...@googlemail.com on 10 Apr 2013 at 6:55

[GoogleCodeExporter]

> Unifying subtitle supersampling behavior between xy-VSFilter & Libass

I asked Chortos to contact YuZhuoHuang privately via email about this a few 
months ago, but never heard anything since. Looking at the Libass issue 
tracker, there doesn't appear to be consensus about making supersampling 
changes, so probably nothing will happen immediately. If there is still 
interest in this after xy_sub_filter is completed, it can be looked into again.

> ASS Header flags for Authored Layout Resolution
> I'd like to start some talks about this

During the past few months, I haven't put anymore thought into whether we 
should support this or not.

Feel free to discuss.

Does usefulness outweigh any downsides?

Implication of adding yet another tag to ASS scripts?

How frequently would such a tag effectively be used by script authors and 
end-users if left completely optional?

Libass developers supportive of such a tag?

Other questions or concerns?

Original comment by cyber.sp...@gmail.com on 11 Apr 2013 at 3:40

[GoogleCodeExporter]

Thanks you for your answers.

> How frequently would such a tag effectively be used by script authors and 
end-users if left completely optional?
I can't talk about other people using this, of course, but I know that many 
people like to re-use subtitle scripts that are already out there for their own 
videos, or they use the exact same ASS script for multiple video resolutions, 
so I can imagine that this tag will indeed be used.  I know that I will use it 
on all ASS scripts I'm going to create for this reason, at least.
Also, this tag will be able to completely replace VSFilter's PAR Compensation 
feature, of which no-one (except maybe the script creators) knows whether it 
should be used for a specific subtitle file or not, for newly created scripts.
All in all, I (optimistically) believe that if people learn about this tag, 
they will use it.

> Implication of adding yet another tag to ASS scripts?
I have no idea how complicated it will be to parse yet another set of Header 
Tags, so I'll leave that issue alone.
What I do know about ASS Headers is that Aegisub itself also stores quite a bit 
of information there that, for the subtitle provider, is completely irrelevant. 
 I'm aware that this can be misunderstood, but I don't mean to criticize this 
behavior, it does make sense and I find it very useful myself.  For that reason 
(and as someone who always edits the Headers before I give my scripts away, 
which I know is not standard), I believe that the added complexity on the User 
side should be minimal, as the position of the tags is pretty much irrelevant 
as long as it's somewhere in the [Script Info] section.
Another implication is that the xy-VSFilter Scale section may need an option to 
use Layout Resolution and only if that information is unavailable to use the 
specified value (Video Resolution or a fixed value).  Although the PAR 
Compensation probably still can't be removed from xy-VSFilter, it maybe could 
be deprecated and work by simply telling the Scale function to use a specific 
set of values (maybe it does that already?  I have no idea how complicated that 
would be, either).

> Libass developers supportive of such a tag?
While I can indeed imagine some interest in this set of tags at libass, I have 
some random memory that tells me they don't like the idea, reasoning that they 
don't like going by the played video's resolution.  I can open a new Issue at 
libass if I don't find out where I remember this from.

> Does usefulness outweigh any downsides?
As I already stated above, I have no idea how complicated this will be to 
implement, so this is definitely a downside.  Another possible downside is that 
if the libass developers don't show any interest in implementing this, it will 
serve to further differentiate the outputs of VSFilter, xy-VSFilter, and 
libass.  If this is something we can live with (I know I can live with it if it 
means I'm getting more accurate [relative to the original source] results from 
xy-VSFilter), this shouldn't be a concern.
For untagged scripts, special treatment will be unnecessary, while for tagged 
scripts, the User can leave setting the right Scale values to xy-VSFilter 
itself, which I consider very useful.  Also, it gives script creators an 
unambiguous way to define how scripts should be rendered, which will be even 
more important for DVD-resolution video, where until now, you basically have to 
guess whether to use PAR compensation or not, which I consider a big plus.  
Also, as already mentioned, it makes multi-resolution releases much easier to 
create, which also means there's less room for error.  Finally, having a Layout 
Resolution that's equal to either the Script Resolution or the Video Resolution 
won't do any harm, so I don't consider this a problem at all.  At least for me, 
the usefulness far outweighs the downsides, even if I have to tag all my script 
files by hand.

> Other questions or concerns?

- How should we name the Header fields?
  I propose we call the header fields LayoutResX and LayoutResY, in order to make them similar in naming to PlayResX/Y and therefore also easier to insert into script Headers.  One can even copy the PlayRes fields and then modify only the parts where it's needed.

- Should Aegisub offer a way to set these fields on request or even 
automatically?
  I'm honestly not sure.  It would be nice to have the option to let Aegisub set these fields for you, but at least if it's done automatically, it's no longer a completely optional field.  Also, this requires additional work from the Aegisub developers.  At least for now, I'm content with being able to set these tags by hand, so I don't see an immediate need for it.

Original comment by TheDarkS...@googlemail.com on 11 Apr 2013 at 8:28

[GoogleCodeExporter]

Some more musings about ASS Layout Resolution tagging:
- I opened an issue about this over at libass, it can be found here: 
http://code.google.com/p/libass/issues/detail?id=102
- I completely forgot about this aspect until now, but if we allow the Layout 
Resolution to be tagged, the xy-VSFilter Scale function should be used for 
content that is not sent via the new subtitle interface as well.  I don't 
consider this a problem because the Scale Test Builds already explicitly 
support drawing subtitles at another Layout Resolution on top of the video.  In 
fact, this may even be seen as a positive aspect, because this way the code 
currently in the testing builds won't go to waste.
- I still favor LayoutResX/Y as the name of these tags, but due to the lack of 
comments on this matter, I haven't heard many opinions.  I'm thinking about 
opening a separate issue for this, as this will enable me to add comments on 
this matter without triggering notifications for everyone.

> Another implication is that the xy-VSFilter Scale section may need an option 
to use Layout Resolution
> and only if that information is unavailable to use the specified value (Video 
Resolution or a fixed value).
Please disregard this part, I forgot that the Scale tab is only going to be 
present in the testing builds.

Original comment by TheDarkS...@googlemail.com on 14 May 2013 at 4:08

[GoogleCodeExporter]

>I still favor LayoutResX/Y as the name of these tags,

This sounds like a bad idea. I suggest introducing a single header flag only 
(similar to the ScaledBorderAndShadow flag), which will allow the subtitle 
renderer to scale transparently to screen resolution.

Original comment by nfxjfg@googlemail.com on 16 May 2013 at 10:29

[GoogleCodeExporter]

Thanks for the feedback.  Would something like
Layout: 1280x720
be better-suited or did you think of an entirely different concept?

Original comment by TheDarkS...@googlemail.com on 16 May 2013 at 11:49

[GoogleCodeExporter]

>Layout: 1280x720

I don't see how this is necessary. All you need something is like:

BrokenVSFilterScaling: no

(Where "yes" is unfortunately the current/traditional behavior.)

It would also be nice if vsfilter-xy could handle font scaling like libass in 
this case: don't stretch the font to force the script aspect to display aspect.

For example, if PlayResX=1000 and PlayResY=500, and screen width=2000, 
height=500, the font should use a 1:1 PAR, instead of stretching the font 
horizontally. libass generally computes the font size out of PlayResY and 
display height, and uses a PAR as requested by the video player. Not letting 
the script dictate the PAR actually solved a lot of problems that libass had 
with scripts in the past, and allows rendering anamorphic video with subs 
correctly, no matter whether the output is on a 1:1 monitor, or renders into an 
"unstretched" video frame.

I didn't read all the tl;dr in this ticket, sorry if I'm overlooking something 
obvious.

Original comment by nfxjfg@googlemail.com on 16 May 2013 at 2:23

[GoogleCodeExporter]

I think I finally understood what this is about: completely 
video-size-independent script rendering; and it sounds like a good idea. But I 
agree that a single flag is enough. You could even call it ScaledBlur by 
analogy with ScaledBorderAndShadow, which it would complement.

But, wm4, how does the PAR stuff make sense? I don't see why the X size should 
be ignored in an ideal world. Quite the opposite, I think it is only ignored 
because VSFilter has done so in the past, and making full use of it would 
resolve all problems. If your script uses 1:1 coordinates, put the 
1:1-corrected picture size in the headers. If your script uses 
anamorphic-condensed coordinates for some reason, put the anamorphic picture 
size in the headers. If you're outputting on a 1:1 monitor, render at 1:1. If 
you're outputting an "unstretched" video frame, you need to compensate by 
condensing the coordinates anyway. (Also note that fonts are not the only thing 
affected by this; everything is affected.)

Original comment by chortos@inbox.lv on 16 May 2013 at 3:11

[GoogleCodeExporter]

>But, wm4, how does the PAR stuff make sense?

In short, the script shouldn't be able to dictate the PAR. This would 
completely break using scripts on videos with different video aspect ratio (not 
just different PAR) and would generally make things worse instead of better.

>Also note that fonts are not the only thing affected by this; everything is 
affected.

It appears libass explicitly has a different horizontal scale factor for fonts 
and the \pos tag. Look out for font_scale_x. I have no idea how much this makes 
sense, though.

Original comment by nfxjfg@googlemail.com on 16 May 2013 at 3:37

[GoogleCodeExporter]

It's called font_scale_x, but it's used for everything.

> This would completely break using scripts on videos with different video 
aspect ratio (not just different PAR)
Of course. There is no general way to handle videos with different display 
aspect ratios.

And if you don't let the script define the aspect ratio of its virtual pixels, 
you break all typesetting.

Original comment by chortos@inbox.lv on 16 May 2013 at 3:51

[GoogleCodeExporter]

>It's called font_scale_x, but it's used for everything.

From what I see, \pos tags still use the script resolution. For example, with 
PlayResX=1000, \pos(1000,123) still ends up on the very right border of the 
output, even if the font_scale_x is set to something other than 1.

>And if you don't let the script define the aspect ratio of its virtual pixels, 
you break all typesetting.

It "breaks" the aspect ratio for fonts, and saves you from getting a weird mess 
with broken scripts.

I think this is the commit that explicitly introduced this behavior: 
http://repo.or.cz/w/libass.git/commit/51e11115fcd18b6e7e02b24608928907cd36987f

Unfortunately, it doesn't give a reason or a test case.

Original comment by nfxjfg@googlemail.com on 16 May 2013 at 4:01

[GoogleCodeExporter]

> I forgot that the Scale tab is only going to be present in the testing builds.

If you are talking about "Renderer Layout Options" on the More tab, while it 
was originally added for testing purposes, we don't have plans to disable that 
functionality.

> BrokenVSFilterScaling: no

The "Layout Resolution tagging" DarkSpaces brought up, was more about have a 
more automated way to override VSFilter's font layout resolution. Mainly it 
would be useful so a script could just be authored once with VSFilter, and then 
scaled perfectly with videos of any resolution and aspect ratio. xy-VSFilter's 
scale function was designed with this capability in mind. If we are going to 
support any tag to override how layout is performed, it would need to 
authoritatively infer the layout resolution which the script was authored, 
while not changing VSFilter's PlayResX/Y handling logic at all.

> It would also be nice if vsfilter-xy could handle font scaling like libass
> in this case: don't stretch the font to force the script aspect to display 
aspect.

We currently intend on adding a non-default toggle for XySubFilter (new 
subtitle interface) so it performs layout at "arAdjustedVideoSize" instead of 
"originalVideoSize". Such on option would essentially only have an effect on 
anamorphic video, for scripts which are not created with VSFilter anamorphic 
font stretching behavior in mind.

> Unfortunately, it doesn't give a reason or a test case.

"Ignore PlayResX/Y aspect ratio for font aspect ratio" is a VSFilter behavior. 
In VSFilter, the primary purpose of PlayResX/Y is to define tags which make use 
of x/y coordinates. PlayResX/Y is handled as an entirely separate plane of 
existence, whenever it doesn't match the resolution which font layout is 
performed.

Original comment by cyber.sp...@gmail.com on 17 May 2013 at 9:11

[GoogleCodeExporter]

> It "breaks" the aspect ratio for fonts, and saves you from getting a weird 
mess with broken scripts.

Certainly, the current behaviour is needed for some existing scripts. But not 
for scripts in the ideal world enabled by the new ScalingMakesSense:yes header.

> It appears libass explicitly has a different horizontal scale factor for 
fonts and the \pos tag.
> From what I see, \pos tags still use the script resolution. For example, with 
PlayResX=1000, \pos(1000,123) still ends up on the very right border of the 
output, even if the font_scale_x is set to something other than 1.

You're right, sorry. Although I still want to note that font_scale_x is used 
for all widths including those of \p drawings, not only of actual font glyphs. 
I'd prefer to call it the "width" scale factor and {rendering width divided by 
PlayResX} the "horizontal position" scale factor.

But here's the thing: there's absolutely no need for them to be separate in the 
ideal world. Define ScalingMakesSense:yes as follows:

final_render = video.resample(PlayResX, PlayResY).render(subtitles, 
PAR=1).resample(final_width, final_height)

and you get a consistent rendering with no need for any other parameters. It 
doesn't matter if the video is anamorphic or rescaled, as long as the picture 
stays the same.

> If we are going to support any tag to override how layout is performed, it 
would need to authoritatively infer the layout resolution which the script was 
authored, while not changing VSFilter's PlayResX/Y handling logic at all.

What's wrong with always setting the layout resolution to exactly PlayResX/Y in 
the perfect scaling mode?

Is this aimed at old or new scripts? There's no reason to allow arbitrary 
layout resolutions in new scripts, and increasing complexity to ease fixing old 
scripts when we can instead decrease complexity doesn't exactly sound like a 
good idea to me.

(from #c24)
> Finally, having a Layout Resolution that's equal to either the Script 
Resolution or the Video Resolution won't do any harm, so I don't consider this 
a problem at all.

1. It gets even harder to understand and reason about all these resolutions. As 
this thread shows already, even the existing two resolutions are badly 
understood.
2. It increases the amount of redundant and semi-useless information present in 
the headers and available to the renderer.
We already have two resolutions, and they're perfectly enough to do consistent 
scaling, so why add another?

Original comment by chortos@inbox.lv on 17 May 2013 at 11:04

[GoogleCodeExporter]

> What's wrong with always setting the layout resolution to 
> exactly PlayResX/Y in the perfect scaling mode?

There is no guarantee that the Layout resolution the script was authored at was 
equal to PlayResX/Y. This is what I mean by "authoritatively infer the layout 
resolution". If this was done with a Boolean tag, that's the information it 
would need to provide.

> Is this aimed at old or new scripts?

The main benefit of explicitly tagging the authored layout resolution would 
indeed be to recover the potentially millions of existing older script which 
had a mismatch between PlayResX/Y and the layout resolution which the script 
was authored to. Currently such scripts cannot be scaled properly without 
knowledge of the authored layout resolution.

Secondary benefit of explicit tagging would be more for debugging, so 
xy-VSFilter's "Renderer Layout Options" "Customize" functionality could be 
accessed in more automated fashion. Essentially it would be useful for me 
personally, when it comes to creating test cases for any bugs in our scale 
function. 

The assumption is that all new scripts will by default be authored with 
matching PlayResX/Y and Layout Resolution in Aegisub, since there is not really 
much benefit of having a PlayRes:Layout mismatch especially now that 
xy-VSFilter supports floating point for all important x/y coordinate tags. Yet 
there being no guarantee that Aegisub default behavior is used, means that 
explicitly tagging the layout resolution wouldn't do any harm other than being 
a bit redundant on most new scripts.

There is a high likelihood we will support explicit layout resolution script 
tagging for these reasons, but there is also no reason we couldn't make it a 
non-default build option so it wouldn't be normally available in public builds. 
I'm sure this functionality could be useful to some people, but currently we 
are hesitant to make it readily available to users unless Libass would also 
support a functionality like this.

> There's no reason to allow arbitrary layout resolutions in new scripts, and 
increasing complexity
> to ease fixing old scripts when we can instead decrease complexity doesn't 
exactly sound like a good idea to me.

Rather than "allow", there is no way to "prevent" arbitrary "PlayResX/Y" 
resolutions in new scripts. As stated above, if there were to be a Boolean tag, 
it would need to state authoritatively that PlayResX/Y is identical to the 
layout resolution which the script was authored. 

We have no intentions to support scaling from PlayResX/Y when there is mismatch 
to the Layout Resolution which the script was authored to. In order to be 
VSFilter compatible, xy-VSFilter's scale function uses Layout Resolution as the 
basis of scaling, not PlayResX/Y (unless they match). Changing handling of 
"arbitrary PlayResX/Y resolution" to something other than VSFilter behavior 
would increase complexity too much. Scaling from Layout resolution when there 
is a mismatch to PlayResX/Y, doesn't increase complexity at all, since it's the 
basis of any VSFilter compatible scaling implementation.

> We already have two resolutions, and they're perfectly enough to do 
consistent scaling, so why add another?

We don't necessarily. I'm currently just against the idea of using PlayResX/Y 
as the basis of scaling when PlayResX/Y is arbitrary.

Explicit Layout Resolution tag: Behavior between xy-VSFilter & Libass could be 
unified when there is either "arbitrary PlayResX/Y" or "matching PlayResX/Y", 
including scaled correctly with script portability.

Boolean Layout & PlayRes Matching tag: Behavior between xy-VSFilter & Libass 
could be unified only when there is "matching PlayResX/Y", including scaled 
correctly with script portability. Instances with "arbitrary PlayResX/Y" would 
possibly not be unified nor be scaled correctly.

Original comment by cyber.sp...@gmail.com on 18 May 2013 at 10:26

[GoogleCodeExporter]

> This would completely break using scripts on videos with different video 
aspect ratio (not just different PAR) and would generally make things worse 
instead of better.
I'm confused.  This sounds as if you'd want to be able to use the same script 
on a 4:3 video that you'd use on a 16:9 video.  But doesn't this imply that for 
those videos, you don't have any position-depending Typesetting or the like 
anyway, so you can just not add the Layout Resolution tags to the script?

About adding a flag to simply tell the Subtitle Renderer whether to scale from 
Script or from Input Video Resolution, I'm against that because the Layout 
Resolution may match neither the Script Resolution nor the Input Video 
Resolution::
1.  A single Boolean flag doesn't tell the Subtitle Renderer if a certain 
script should use PAR Compensation or not - there are ASS Scripts out there 
that should be displayed without PAR Compensation and ones that should use PAR 
Compensation, and both types can use the same Script Resolution.  For these 
cases, this type isn't sufficient to derive the Layout Resolution.
2.  When the flag says to not use Script Resolution, the Subtitle Renderer 
always must assume that the Video Resolution should be used.  However, if the 
user decides to resize their video before sending it to their (Subtitle) 
Renderer of choice for whatever reason, this will produce incorrect results 
(see post #10 which introduced the Scale feature).  Also, this way it will 
still be dependent on the Video Size.
3.  Someone may have made some changes to an ASS Script to match the \blur 
values and such to a new video resolution (but left Script Resolution as it 
was) and muxed that with the new resolution video, and sometime later someone 
else remuxes that script with yet another Video Resolution.  In this case, the 
simple flag will also fail because the "yet another Video Resolution" will be 
used as Layout Resolution, which is wrong.

Also, because this tag is supposed to be completely optional, one can use it 
when it's present and fall back to the default behavior when it's absent.

Original comment by TheDarkS...@googlemail.com on 18 May 2013 at 11:58

[GoogleCodeExporter]

Let's clear the misunderstanding.

You want to use the new flag on old scripts. You want to be able to take an 
existing script, make a single change in it and achieve consistent scaling. 
Yes, in this case you do need to specify the layout resolution.

(By the way, why is it called the "layout" resolution anyway? I usually 
understand layout as including both sizing and positioning.)

We think that if you want to fix an old script, you may as well go the full way 
and actually fix it: change all relevant numbers throughout the script to make 
it use a layout resolution equal to the script resolution, and of course enable 
ScaledBorderAndShadow and the new flag. The new flag only needs to be Boolean 
in this case, much like ScaledBorderAndShadow is only Boolean.

Original comment by chortos@inbox.lv on 19 May 2013 at 12:11

[GoogleCodeExporter]

> Why is it called the "layout" resolution anyway?

Layout Resolution = Video Resolution the script was authored to in Aegisub.

Essentially it's the original viewing resolution of a script.

> I usually understand layout as including both sizing and positioning.

It's the final layout resolution for all subtitles (as performed by VSFilter 
2.39), before xy-VSFilter's scale function is activated. VSFilter does perform 
sizing and positioning based on "layout resolution", but when there is a 
mismatch with PlayResX/Y, it's not a 1:1 mapping. VSFilter superimposes a 
PlayResX/Y grid on top of Layout Resolution (Original Video Resolution), as 
which point relative positions, font sizing, and tag effects are all used for 
final layout.

> We think that if you want to fix an old script, 
> you may as well go the full way and actually fix it

That's non-trivial if you have a lot of complex typesetting. Why spend hours 
when you could just inform the subtitle renderer about the properties of the 
script? Yet this assumes knowledge of how to do this. A typical end-user 
wouldn't have the first clue about how to fix typesetting, so they'd be screwed 
if they wanted to re-use such a script, as is currently the case.

> The new flag only needs to be Boolean in this case, much like 
ScaledBorderAndShadow is only Boolean.

On the topic of ScaledBorderAndShadow, this tag also only applies for 
PlayResX/Y -> Layout Resolution. It has no effect whatsoever when PlayRes & 
Layout Resolution match. Layout Resolution -> Target Resolution, everything is 
scaled no matter what that tag states.

This is one of many reason why I have the requirement that "PlayResX/Y" == 
"Layout Resolution" == "Aegisub Video Resolution" if we are going to use a 
Boolean. Mismatches would break traditional VSFilter.dll horribly, and do more 
harm than good. How do you enforce users honor that other than giving the tag a 
name which implies its purpose, no clue... An optional explicit layout 
resolution tag would have a similar potential to case harm to regular VSFilter, 
but less of an issue since the intended use of the tag would mean that VSFilter 
would already have broken rendering.

Even though xy-VSFilter has made good progress flushing regular VSFilter out of 
the fansubbing world and major codec-packs, I'd suspect that MPC-HC's 
distribution of VSFilter.dll + VSFilter-based MPC-HC ISR still accounts for 
majority presently in-use. Misuse of of any new tag in a way which would break 
compatibility remains a major concern. A prerequisite to making any major 
change to VSFilter's PlayResX/Y handling, is that all current major VSFilter 
distributions need to have unified rendering after such a change, while still 
supporting the traditional VSFilter method for compatibility.

If Libass developers still have a desire for VSFilter completely change 
PlayResX/Y handling and implementation of the ASS Specification in a way that 
breaks traditional VSFilter.dll in normal use, we are not yet at a point where 
that is safe to do. Having explicit layout resolution tagging could essentially 
unify VSFilter & Libass with a VSFilter-compatible implementation of the ASS 
Specification and scaling. Considering Libass already is 90%+ 
VSFilter-compatible today, implementation of a layout resolution override 
should be trivial.

The window of opportunity here isn't unlimited. I won't give any guarantees 
that xy-VSFilter's developer will still be around, if Libass decides to wait it 
out another few years for the prerequisites to be met for an optimal unified 
solution to be implemented which "fixes the ASS specification".

Original comment by cyber.sp...@gmail.com on 19 May 2013 at 11:59

[GoogleCodeExporter]

Well, we at libass are pretty apathetic to such issues. We realized that 100% 
vsfilter compatibility is rather hard to achieve, and doing so adds even more 
hacks to the whole stack (neither vsfilter, the ASS format, or libass are the 
cleanest things in the world). Trying to change ASS semantics to the better 
_while_ staying compatible to old scripts and renderers is even worse. 
Basically, we are not interested in more complexity. We also think that 100% 
compatibility is not always worth the trouble. I realize that you perhaps think 
differently, and prefer if vsfilter-xy gives exactly the same output as classic 
vsfilter whenever possible (at least when rendering to video resolution).

Of course we are not totally opposed to changes of the nature as the one 
discussed in this issue, but we are skeptic.

(I still think the only way to fix the ASS format is to introduce a completely 
new revision of the format. So far many have tried, without any success. Note 
however, that if both vsfilter-xy, libass, and releasers cooperate, this would 
very well be possible, but I don't want to derail this discussion by going too 
far.)

Anyway, my point is: better leave it as dumb as it is, instead of introducing 
additional complexity for marginal improvements. You can't make ASS beautiful 
and nice, all while staying compatible with all the old crap.

Also, maybe I'm missing something obvious. At least with libass' broken blur 
scaling, things should actually be resolution independent. The only exception 
is \pos (and maybe drawings, scaling of them might be slightly buggy in 
libass), but what can you do if the script uses \pos, was authored for 4:3, and 
you try to use it on 16:9 video? For all you know, the expansion 4:3->16:9 
doesn't even need to be centered, but pans around randomly. So what's the 
point? (Blur scaling in libass was recently fixed - probably, and only if the 
player application explicitly informs libass of the video resolution, which 
AFAIK no player does yet.)

>> We think that if you want to fix an old script, 
>> you may as well go the full way and actually fix it

> That's non-trivial if you have a lot of complex typesetting. Why spend hours 
when
> you could just inform the subtitle renderer about the properties of the 
script? 

Shouldn't that be Aegisub's responsibility?

Replying to comment #20...

>VSFilter has always used GDI32 (resolution-dependent, whole pixel 
grid-fitting) internally. I believe eightfold supersampling is required in 
order to have 8x8 sub-pixel positioning in VSFilter, so dropping supersampling 
wouldn't be an option with our present scanline converter.

Can you explain a but more? Why is it 8x8? In my opinion, this super-sampling 
sucks because it doesn't make _anyone_ happy. You still have jerky scaling, and 
you still don't get proper hinting.

>YuZhuoHuang has been considering the prospect of writing a high quality 
floating-point scanline converter with anti-alaising support for xy-VSFilter, 
but at this point it's nothing more than a nice idea & possible long term goal.

Why not use freetype? It does have such a rasterizer, and it's pretty flexible 
about how you feed it data. The input doesn't even have to be a font. Libass 
for example uses it to do ASS vector drawing.

Original comment by nfxjfg@googlemail.com on 19 May 2013 at 12:52

[GoogleCodeExporter]

> Scaling from Layout resolution when there is a mismatch to PlayResX/Y, 
doesn't increase complexity at all, since it's the basis of any VSFilter 
compatible scaling implementation.

It's not so much about the complexity of adapting the existing implementations 
as it is about the complexity of the format and of potentially formalizing and 
reimplementing strict subsets of the format in the future.

> VSFilter does perform sizing and positioning based on "layout resolution", 
but when there is a mismatch with PlayResX/Y, it's not a 1:1 mapping. VSFilter 
superimposes a PlayResX/Y grid on top of Layout Resolution (Original Video 
Resolution), as which point relative positions, font sizing, and tag effects 
are all used for final layout.

In other words, positioning uses the script resolution.

> That's non-trivial if you have a lot of complex typesetting.

Yes and no. Don't you only need to manually rescale numbers: \blur parameters, 
widths and positions? Also, if you have truly complex typesetting, it probably 
uses techniques like single-pixel clipping, so you'll want to redo it for the 
new resolution anyway to achieve the best visual quality.

Oh, it just occurred to me that \blur is circular rather than elliptical. How 
is it handled by xy-VSFilter's scaling function on anamorphic content?

> A typical end-user wouldn't have the first clue about how to fix typesetting, 
so they'd be screwed if they wanted to re-use such a script, as is currently 
the case.

Does a typical clueless end-user actually need to do this? This would normally 
be done by rereleasers, who should have enough skills to do it properly. 
Indeed, currently active rereleasers have to have the skills already, because 
there is simply no other way to fix old scripts at the moment.

> This is one of many reason why I have the requirement that "PlayResX/Y" == 
"Layout Resolution" == "Aegisub Video Resolution" if we are going to use a 
Boolean.

The whole point of a Boolean flag is to define them as equal. Although the 
Aegisub video resolution can be different as long as Aegisub converts 
coordinates and sizes properly. (And it does convert coordinates already.)

> How do you enforce users honor that other than giving the tag a name which 
implies its purpose, no clue...

They just can't not honour this requirement. There's no way for them to force 
the resolutions to diverge. The resolutions cease to be separate entities when 
the new flag is Boolean and set to 'yes'.

> A prerequisite to making any major change to VSFilter's PlayResX/Y handling, 
is that all current major VSFilter distributions need to have unified rendering 
after such a change, while still supporting the traditional VSFilter method for 
compatibility.

Neither proposal involves breaking backwards compatibility: if you don't 
include the new header (or explicitly set it to false if it's Boolean), you get 
the legacy behaviour. At the same time, if you have a script using the new 
header paired with a video whose resolution is different from the original 
video=layout=script resolution, it will be broken in old VSFilter regardless of 
what form the new header takes.

> Considering Libass already is 90%+ VSFilter-compatible today, implementation 
of a layout resolution override should be trivial.

Indeed. Either variant of the new header should be very easy to implement in 
libass.

> Why not use freetype?

Among other reasons, for vertical font support. Unless we can conclusively 
resolve http://code.google.com/p/libass/issues/detail?id=95.

And I do think we should aim for 100% backwards compatibility in the case of 
ASS, both in xy-VSFilter and in libass. But I also agree completely with the 
remark about a new format revision.

Original comment by chortos@inbox.lv on 19 May 2013 at 2:13

[GoogleCodeExporter]

> I realize that you perhaps think differently, and prefer if vsfilter-xy gives
> exactly the same output as classic vsfilter whenever possible (at least when 
> rendering to video resolution).

Yes, at least for the time being. If the time ever comes when:

1) xy-VSFilter's VSFilter.dll superseeds MPC-HC's VSFilter.dll as the majority 
VSFilter distribution

&

2) XySubFilter (new subtitle interface) superseeds MPC-HC ISR for high 
resolution subtitle rendering, as well as gains support in a render other than 
madVR like EVR-CP 

We would then be open to adding a tag which would result in disruptive changes 
to how VSFilter handles rendering. The question is if xy-VSFilter will ever 
reach this point. Only baby steps can be made towards this goal until 
XySubFilter and the new subtitle interface implementations are stable. And then 
we are left with the unknown if MPC-HC project would be willing to scrap their 
current ISR and adopt XySubFilter in its place with support in their default 
EVR-CP renderer. Many unknowns.

> I still think the only way to fix the ASS format is to introduce a completely 
new revision of the format.

This is a sentiment I also share. I still remember that AS5 specification 
http://devel.aegisub.org/export/56bd16dfdffbd8b8ff1413f3d015daa132ae19f0/docs/sp
ecs/as5/as5.pdf which was being worked on at one point, but was left 
half-finished many years ago. We are long overdue for a successor to ASS 
format, but the problem is there has never really been an outcry for this to 
occur by people who use ASS. Fansubbers in general seem content with the 
current status quo and VSFilter limitations of the ASS spec, which could make 
user transition to a new spec take a long time.

> Anyway, my point is: better leave it as dumb as it is, instead of introducing 
additional complexity for marginal improvements.
> You can't make ASS beautiful and nice, all while staying compatible with all 
the old crap.

Well if the long-term goal is to replace the ASS format with a new 
specification, any changes should continue our current trend of marginal 
improvements to useability, at the cost of complexity to maintain VSFilter 
compatibility.

> Also, maybe I'm missing something obvious. At least with libass' broken blur 
scaling, 
> things should actually be resolution independent, but what can you do if the 
script uses \pos, was authored for 4:3, 
> and you try to use it on 16:9 video? For all you know, the expansion 
4:3->16:9 doesn't even need to be centered,
> but pans around randomly.

I'm not positive what you are talking about here. 

1) Author script to a 4:3 layout resolution on a 4:3 video
2) Resize video 4:3 to 16:9
3) Use script which was authored to 4:3 on resized 4:3 -> 16:9 video

XySubFilter Result = Subtitles and effects rendered with anamorphic 4:3 -> 16:9 
rendering, with all typesetting maintaining relative positions on the 4:3 -> 
16:9 resized video. The /blur and /be algorithms used by our scale function are 
have separate x & y parameters which are capable of anamorphic blur rendering.

> Shouldn't that be Aegisub's responsibility?

Optimally it would, but unfortunately Aegisub's Resample Resolution function 
doesn't handle complex typesetting w/ mismatched playres very well. Last time I 
tested it, there was still a lot of manual effort and typesetting knowledge 
needed to fix everything up afterwords to look as expected. Part of the problem 
is that perfect scaling complex scripts does not always translate directly to 
functionality exposed by ASS tags, and is best performed by the subtitle 
renderer.

> Can you explain a but more? Why is it 8x8? In my opinion, this super-sampling 
sucks because it doesn't make _anyone_ happy. 
> You still have jerky scaling, and you still don't get proper hinting.

Considering VSFilter originally developed in the Windows 98 timeframe, 8x8 was 
probably used because it was good-enough quality without significant speed 
penalty for CPUs at the time. The other concern, especially nowadays with 4K 
video approaching, is RAM requirements. VSFilter literally supersamples 
_everything_ to 8x8 for the purpose of anti-aliasing & sub-pixel positioning, 
which as JEEB @ CCCP recently discovered, can occasionally cause 32-bit Windows 
to exceed its 2GB process limit. This is a limitation of VSFilter's scanline 
converter, which is unable to perform anti-alaising like FreeType does.

> Why not use freetype? It does have such a rasterizer, and it's pretty 
flexible about how you feed it data.

I'm unsure how much he looked into it, but he seemed to have concerns the 
FreeType would not be compatible with xy-VSFilter. Which likely means that if 
we used FreeType, much of his work thus far on xy-VSFilter would potentially 
need to be discarded and re-written from scratch. If someone wants to use 
FreeType, they'd probably be much better off just writing a Libass DirectShow 
filter. He believed that writing a brand-new scan line converter from scratch 
to xy-VSFilter's exact requirements, could offer similar or ever higher quality 
than FreeType, while at the same time increase xy-VSFilter performance rather 
significantly.

> It's not so much about the complexity of adapting the existing 
implementations as it is about the complexity 
> of the format and of potentially formalizing and reimplementing strict 
subsets of the format in the future.

While a valid concern, I don't really see the ASS format having much of a 
future beyond VSFilter & Libass support, even its current state. The ASS format 
itself a dead-end.

> In other words, positioning uses the script resolution.

Yes, but layout is not performed at script resolution. Semantics, but the term 
"layout" make sense for VSFilter.

> Oh, it just occurred to me that \blur is circular rather than elliptical. How 
is it handled by xy-VSFilter's scaling function on anamorphic content?

As mentioned above, in the process of developing the xy-VSFilter scale 
function, our \blur and \be algorithms were modified to support anamorphic blur 
rendering. You'd need to look at our source code, since I don't remember the 
technical details off-hand.

> Does a typical clueless end-user actually need to do this?

I'd argue yes. If we ever reach a point in the future that traditional fansub 
video releases die off for one reason or another, a functionality like this 
could allow for high quality typesetting in script only releases which could be 
used with any raw. The typical clueless end-user is probably more familiar with 
subtitle time shifting, than your average fansub viewer.

> There's no way for them to force the resolutions to diverge. 
> The resolutions cease to be separate entities when the new flag is Boolean 
and set to 'yes'.

If the video is authored at 1920x1080, but the PlayResX/Y is 1280x720, the 
resolutions have diverged. Boolean set to 'yes' would mean that layout would be 
performed at 1280x720 and then scaled to 1920x1080. Script authoring would 
occur at 1920x1080, not 1280x720. This would cause problems for traditional 
VSFilter which doesn't support the new Boolean flag.

> At the same time, if you have a script using the new header paired with a 
video whose resolution is different from the
> original video=layout=script resolution, it will be broken in old VSFilter 
regardless of what form the new header takes.

That is only true when a script was authored with "original video=layout=script 
resolution". 

If layout resolution == script resolution != original video resolution, 
explicit tagging would allow old VSFilter to work at original video resolution, 
while a Boolean tag would be broken with old VSFilter at original video 
resolution. The different being that with explicit tagging, the script would 
always be authored in a VSFilter compatible way to the original video 
resolution.

Original comment by cyber.sp...@gmail.com on 19 May 2013 at 8:33

[GoogleCodeExporter]

> If layout resolution == script resolution != original video resolution, 
explicit tagging would allow old VSFilter to work at original video resolution, 
while a Boolean tag would be broken with old VSFilter at original video 
resolution. The different being that with explicit tagging, the script would 
always be authored in a VSFilter compatible way to the original video 
resolution.

I don't follow.

You have layout = script resolution. Whether you put "Layout: WxH" or 
"NewBooleanFlag: yes", you inform the new-header-aware renderer that layout = 
script resolution. The video resolution is irrelevant at this point; both 
variants of the header have identical behaviour. Then after this, the renderer 
rescales from layout to video resolution.

You also have script != video resolution. So a VSFilter that doesn't understand 
the new header will set the layout resolution to the video resolution, breaking 
the rendering. What form the new flag takes is completely irrelevant because 
it's not taken into account.

Original comment by chortos@inbox.lv on 19 May 2013 at 9:00

[GoogleCodeExporter]

You need to think about how the script is authored.

The purpose of a boolean tag is to specify that PlayResX/Y is to be used for 
layout prior to scaling
PlayResX/Y = 640x480
Video Resolution = 1280x720
BrokenVSFilterScaling: no
Script author intends to release with 1280x720 MKV only
Result: Old VSFilter broken. PlayResX/Y mismatch handling during authoring is 
not compatible with VSFilter.

The purpose of an explicit tag is to specify the authored video resolution to 
use for layout prior to scaling
PlayResX/Y = 640x480
Video Resolution = 1280x720
Layout Resolution: 1280x720
Script author intends to release with 1280x720 MKV only
Result: Old VSFilter renders correctly. PlayResX/Y mismatch handling during 
authoring is VSFilter compatible.

Original comment by cyber.sp...@gmail.com on 19 May 2013 at 9:39

[GoogleCodeExporter]

The purpose of a boolean tag is to specify if PlayResX/Y matches authored Video 
Resolution and if so, to be used for layout prior to scaling
PlayResX/Y = 640x480
Video Resolution = 1280x720
PlayResMatchesVideo: no
Script author intends to release with 1280x720 MKV only
Result: Old VSFilter renders correctly. PlayResX/Y mismatch handling during 
authoring is VSFilter compatible.

To add to the previous comment, this is why a boolean would need to have the 
specified purpose of defining if PlayResX/Y is the same as the authored video 
resolution or not, in order to maintain VSFilter compatibility. It would 
restrict PlayRes mismatch to VSFilter style rendering.

Original comment by cyber.sp...@gmail.com on 19 May 2013 at 10:16

[GoogleCodeExporter]

But of course. If someone's releasing for a 1280x720 video and they want to 
achieve compatibility with old VSFilter, they should use a 1280x720 script 
resolution. This isn't even anything new; typesetters have been saying this for 
many years. Why would you want to specifically support making new scripts with 
wrong resolutions compatible to old filters using a new header?

You can always break old VSFilter by changing the video resolution.

A new feature should not be defined by the deficiencies in the old version. The 
whole point of adding a new feature is to overcome them. If someone wants their 
script to be compatible with old VSFilter, they'll have to use layout = 
released video resolution. Assuming they have such a released video resolution 
at all. But that shouldn't stop someone who doesn't care about old VSFilter 
from setting them to different values. The result will be fine in new VSFilter, 
and it will be trivial to break the result in old VSFilter in either case.

Isn't the whole point of the new header to allow changing video resolution with 
no script modifications? This will be impossible in old VSFilter no matter what 
form the new header takes.

And more generally, old renderers should not be a deterrent to adding new 
features. New scripts are aimed at new renderers. If new scripts are perfectly 
compatible with old renderers after the introduction of a new feature, the new 
feature must be a no-op. As long as it causes the minimum required amount of 
breakage, it's fine. If your output is broken, upgrade your renderer. All 
software works this way, and subtitle renderers aren't any special. In fact, 
anything that uses new ASS most likely also uses new video and audio codecs and 
container features, so you need new codecs/filters anyway.

(In particular, I completely disagree with a certain Aegisub blog post from a 
few years ago that begged for ASS to be frozen. xy-VSFilter has already 
introduced, to great success, extensions to existing tags and a new header, and 
I'm all for adding new tags if they're useful.)

Original comment by chortos@inbox.lv on 19 May 2013 at 10:30

[GoogleCodeExporter]

As mentioned in my previous comments, IMHO xy-VSFilter does not yet have large 
enough user-base to implement a major change in behavior which could break 
compatibility with normal VSFilter through one of its potential uses.

> Why would you want to specifically support making new scripts with wrong 
resolutions 
> compatible to old filters using a new header?

All the legacy scripts in existence with PlayResX/Y mismatches is not because 
VSFilter specifically supported it. It was the opposite that VSFilter was 
broken with PlayResX/Y mismatches, but guess what, you still occasionally see 
scripts authored specifically for that brokenness today. There is no reason the 
same trend wouldn't continue with a new tag which defined PlayResX/Y layout. 
Personally I see PlayResX/Y layout allowing arbitrary scaling during authoring 
as one of it's potential use cases, but this is of course completely 
incompatible with normal VSFilter, which is why I'm against supporting 
unrestricted PlayResX/Y layout currently.

> Isn't the whole point of the new header to allow changing video resolution 
with no script modifications?

Yes and no.

Yes, the whole point of an explicit layout resolution header would be to enable 
script portability and nothing more.

No, the whole point boolean tag to enable PlayRes layout is primarily to break 
compatibility with VSFilter and introduce more intuitive scaling going forward. 
Restrictive script portability is only a side-effect.

> If new scripts are perfectly compatible with old renderers after the 
introduction of a new feature, the new feature must be a no-op.

The general idea is for new scripts features to not break old renderers in any 
significant way. At the very least, if a new feature breaks rendering 
compatibility with new scripts, that same new feature should fix something on 
existing scripts which is of greater benefit than what it breaks. 

Arguably the most harmful 'feature' we've introduced in xy-VSFilter which broke 
old renderers, were our massive performance enhancements. What started out in 
the beginning as something targeted at enabling old CPUs to play the most 
intense karaoke/typesetting releases of that time, quickly turned into scripts 
being authored with an order of magnitude more complexity. Worse-case I've seen 
released scripts which would case old VSFilter would render at <1fps, Libass 
<23fps, while xy-VSFilter would render at >100fps. This new trend has become a 
bit of a problem recently.

Lesson learned. New features will likely be exploited in unexpected/unintended 
ways, potentially causing legacy implementations to break.

> I completely disagree with a certain Aegisub blog post from a few 
> years ago that begged for ASS to be frozen.

I'm the opposite and have completely agreed with that jfs Aegisub blog post 
before I even got involved with the xy-VSFilter project. All changes and 
enhancements we have made to xy-VSFilter up to to point, have been carefully 
assessed to not have a significant impact on existing VSFilter implementations 
with both legacy and new scripts. I do not consider a new boolean header like 
"BrokenVSFilterScaling: true/false" to fall under the umbrella of low impact 
changes.

Original comment by cyber.sp...@gmail.com on 20 May 2013 at 1:03

[GoogleCodeExporter]

> I completely disagree with a certain Aegisub blog post from a few 
> years ago that begged for ASS to be frozen.
Aegisub devs are absolutely right.
Small changes that also may fix something along the way is ok. As long as 
they're not affecting old scripts much. Because vsfilter doesn't give you any 
choice sometimes. 
Everyone should agree that having no real standard is a bad thing. But by 
extending ASS in incompatible way you're actually saying:
"I don't care about standards,  I only want to make my software look good. And 
it's the problem of other devs if they want to follow my example or not"
You're also discouraging creation of the new format.
I don't really understand why suddenly it turned out that opinion of the libass 
devs matters. Why not just let them walk their own path as they always did... 
In fact they should follow vsfilter's example not the other way.

Original comment by Gagaron...@gmail.com on 20 May 2013 at 8:14

[GoogleCodeExporter]

The Boolean form of the new header isn't breaking anything. Or rather, both 
forms are equally breaking.

You have no way of knowing which resolution is "the authoring" video 
resolution. A restriction can be built into Aegisub; I have no objections to 
that. But nothing prevents the script author from releasing their script with a 
video different from the one they used in Aegisub. Or without any video at all. 
Or without using Aegisub. Breaking old VSFilter is trivial no matter what the 
new header looks like.

> you still occasionally see scripts authored specifically for that brokenness 
today. There is no reason the same trend wouldn't continue with a new tag which 
defined PlayResX/Y layout.

So are you saying people will add the new header but design for old VSFilter, 
thus making the new header useless in practice? I think people who use Aegisub 
design for whatever Aegisub uses, which hopefully corresponds to the headers 
Aegisub sets. And once more, if this is an issue, Aegisub can simply enforce 
the script = layout = video resolution equality on its own. Of course, people 
can still change the video resolution later and keep designing for old 
VSFilter, but they can do this with either variant of the new header.

It all boils down to "aimed at new or old scripts?" The Boolean variant is 
aimed at new scripts, so enforcing resolution equality in Aegisub is perfectly 
fine.

> No, the whole point boolean tag to enable PlayRes layout is primarily to 
break compatibility with VSFilter and introduce more intuitive scaling going 
forward.

> I'm against supporting unrestricted PlayResX/Y layout currently.

It has nothing to do with breaking compatibility. It's not breaking any more 
than your proposed tag is. The Boolean variant is just a special case of the 
non-Boolean variant; how can it be more breaking or unrestricted?

> Small changes that also may fix something along the way is ok. As long as 
they're not affecting old scripts much.

Once again, there are no changes that affect old scripts. New renderers are 
compatible with old scripts. New scripts don't have to be compatible with old 
renderers.

> I don't really understand why suddenly it turned out that opinion of the 
libass devs matters. Why not just let them walk their own path as they always 
did... In fact they should follow vsfilter's example not the other way.

> But by extending ASS in incompatible way you're actually saying:
"I don't care about standards,  I only want to make my software look good. And 
it's the problem of other devs if they want to follow my example or not"

Wait, didn't you just say that you didn't care about other devs' opinions and 
that it's their problem to follow VSFilter's example?

I don't want changes to be incompatible:

* Backwards compatibility: I definitely want old scripts to be compatible with 
new renderers. I'm against the introduction of changes just for the sake of 
breaking old renderers, too.† But if something can be improved in new 
renderers, nothing should prevent this from happening. Naturally, old renderers 
will not get the improvement.

* Portability: that's precisely why we're discussing this together.

(† Although--I'm not advocating this, but--this would be an easy way to 
ensure we get rid of old renderer installations and partial compatibility 
problems. Also, a new format, which I do support, would essentially just be 
this taken to the extreme.)

Original comment by chortos@inbox.lv on 20 May 2013 at 10:48

[GoogleCodeExporter]

> I don't really understand why suddenly it turned out that opinion of the 
libass devs matters.

Honestly, I was leaning towards "do nothing", until DarkSpaces revived the 
issue and grabbed the attention of the Libass developers. If no agreement is 
reached, we'll probably either go back to our previous "do nothing" mindset or 
possibly consider making it an undocumented feature.

Adding any new header functionality to scripts is potentially disruptive. 
Libass not supporting a new header would limit its usefulness into the future. 
Worse case, Libaas would decide to add support for a different header 
functionality than we do, causing a split in the ASS format. Unified handling 
of scripts between all renders should be strived for, whenever possible. In 
most cases this means forcing adaption to legacy VSFilter behavior, but in 
special cases an acceptable compromise can be reached.

> The Boolean form of the new header isn't breaking anything.
> Or rather, both forms are equally breaking.

Potentially equally breaking. The problem in both cases is VSFilter 
incompatible use of the headers during script authoring. I see this more likely 
to occur with a Boolean compared to a Explicit header. A Boolean gives the 
potential that VSFilter breaking behavior could be enabled by default for all 
script during authoring, without much thought. With an explicit layout 
"original video resolution" header, it at least requires more conscious thought 
by the user about what they are doing.

> A restriction can be built into Aegisub

Last I heard, Aegisub was not supportive of adding built-in support for any 
such layout override header, because all solutions were sub-optimal. This is 
part of the reason why I prefer approaching this from the direction of 
recovering old scripts, rather then being used on new scripts. A new header 
should be entirety optional, manually added, with a very limited and special 
use-case for new scripts. Having a boolean header gives higher potential for a 
general use-case into the future, which I see as a problem currently.

> So are you saying people will add the new header but design for old VSFilter,
> thus making the new header useless in practice?

Yes, with the new header people should continue to design for old VSFilter. 
Yes, by default at original video resolution, the new header should have no 
effect when enabled.
No, the header _would_ be useful whenever a script is used with a video of a 
different resolution.

> You have no way of knowing which resolution is "the authoring" video 
resolution.

It's assumed to be the original video resolution which the script was paired 
with. This is the same assumption which our scale function in the new subtitle 
interface makes automatically. Any script which doesn't comply by this today is 
broken in all renderers.

> It all boils down to "aimed at new or old scripts?"

The idea was to aim this primarily at old scripts, but with a limited special 
use-case for new scripts as well.

> The Boolean variant is just a special case of the non-Boolean variant; how 
can it be more breaking or unrestricted?

As shown in my previous examples, the non-Boolean variant defaults to VSFilter 
compatible behavior when used as intended. The Boolean variant potentially 
defaults to VSFilter incompatible behavior when used as intended. I have my 
lingering fears that a Boolean header could be the trigger and act as 
encouragement for even more major changes into the future, which could break 
VSFilter compatibility with the ASS format completely.

One thing I've learned from our YCbCr Matix header, is that fansubbers value 
legacy VSFilter compatibly greatly. After we introduced the header, it actually 
*reduced* the number of BT.709 scripts in general circulation. It has also 
exhibited responsible behavior to not abuse an explicit tag.

> New scripts don't have to be compatible with old renderers.

Disagree. Breaking compatibility with old renderers is synonymous with breaking 
compatibility with the ASS format.

> Backwards compatibility

Your standards for backwards compatibility in new scripts seems much less 
strict then our own.

> Portability: that's precisely why we're discussing this together

BrokenVSFilterScaling has a negative connotation which implies it should be 
used with the intention of breaking VSFilter compatibility. I do not consider 
enabling the VSFilter incompatible behavior which libass supported in its early 
days many years ago, to be primarily about script portability. It make me sense 
ulterior motives for making larger changes into the future.

> Although--I'm not advocating this, but--this would be an easy way to ensure 
we get rid of old 
> renderer installations and partial compatibility problems.

While true, I much prefer the natural process of slowly getting rid of old 
renderer installations over time. Our performance enhancements have already 
caused well enough user grief with forced updates, which has accelerated 
xy-VSFilter's adoption rate.

Original comment by cyber.sp...@gmail.com on 20 May 2013 at 1:42

[GoogleCodeExporter]

I can't speak for Grigori and wm4, but I'll be all for implementing the new 
header in libass even if it ends up taking the form you're suggesting. And 
indeed, I'll be lazy and use it whenever I need to adapt old scripts to new 
videos. But I believe it's the wrong solution.

> Last I heard, Aegisub was not supportive of adding built-in support for any 
such layout override header, because all solutions were sub-optimal.

I don't see how it is sub-optimal, although of course saying this to you 
doesn't affect Aegisub.

> This is part of the reason why I prefer approaching this from the direction 
of recovering old scripts, rather then being used on new scripts. A new header 
should be entirety optional, manually added, with a very limited and special 
use-case for new scripts.

Aren't you saying you want old scripts to scale perfectly but not new scripts? 
Beside new scripts just being broken, this will mean they'll need to patched 
later when they're "old"... in the same manner. And you're also saying you want 
to hide the new feature, which will only ensure nobody uses it even on old 
scripts.

> Having a boolean header gives higher potential for a general use-case into 
the future, which I see as a problem currently.

How can potential for improvement even be seen as a problem?

> Yes, with the new header people should continue to design for old VSFilter. 
> Yes, by default at original video resolution, the new header should have no 
effect when enabled.
> No, the header _would_ be useful whenever a script is used with a video of a 
different resolution.

Naturally, typesetters who care about the compatibility of their new scripts 
with old VSFilter will aim for it, and the new header should not prevent them 
from achieving it. And neither variant does. By this:

>>> you still occasionally see scripts authored specifically for that 
brokenness today. There is no reason the same trend wouldn't continue with a 
new tag which defined PlayResX/Y layout.

>> So are you saying people will add the new header but design for old 
VSFilter, thus making the new header useless in practice?

I meant that if people commonly add the header, ignore the rendering in new 
VSFilter, look only at the output of old VSFilter and end up breaking *new* 
VSFilter, the header's practical usefulness will be lost. If they do look at 
new VSFilter and make sure their script is compatible with both new and old, 
what's the problem?

>> You have no way of knowing which resolution is "the authoring" video 
resolution.

> It's assumed to be the original video resolution which the script was paired 
with.

Yes. But VSFilter has no way of confirming this. The fansubber, rereleaser or 
end-user can very easily break old VSFilter by violating this. The new header 
isn't going to prevent this.

> The Boolean variant potentially defaults to VSFilter incompatible behavior 
when used as intended.

No. It "defaults" to video = layout = script just as the non-Boolean variant 
"defaults" to video = layout.

> I have my lingering fears that a Boolean header could be the trigger and act 
as encouragement for even more major changes into the future, which could break 
VSFilter compatibility with the ASS format completely.

Like a new subtitle format? You seem to support that idea for some reason.

But no, the Boolean variant is literally a special case of the non-Boolean one.

> One thing I've learned from our YCbCr Matix header, is that fansubbers value 
legacy VSFilter compatibly greatly.

That sounds interesting, because in my experience pretty much all anime 
fansubbers say "Use the latest xy-VSFilter [or some filter pack that includes 
it]. If you use anything else and get broken results, we don't care." Yes, 
fansubbers want their existing scripts, skills and knowledge to continue to 
work with and apply to new subtitle renderers. No, they don't have any qualms 
about making new scripts incompatible with old renderers.

Look at the top of this page (if you're reading this on Google Code). Who's 
that who originally suggested full resolution independence while actually 
dropping compatibility with old scripts even? Oh, it's a well-known fansubber 
and in particular typesetter.

> After we introduced the header, it actually *reduced* the number of BT.709 
scripts in general circulation.

It helped educate typesetters who weren't aware of the issue.

> Breaking compatibility with old renderers is synonymous with breaking 
compatibility with the ASS format.

A little bit. And so what? All previous changes that have ever been made to 
ASS--or any other data format--"broke" compatibility of old software with new 
files. When the new subtitle format to replace ASS is finally created, it will 
be incompatible with old VSFilter as well. Are you that concerned about many 
modern Web sites looking horribly wrong and/or not behaving as expected in 
six-year-old browsers?

> BrokenVSFilterScaling has a negative connotation which implies it should be 
used with the intention of breaking VSFilter compatibility.

You seem to be taking that half-joke name far too seriously. I've suggested 
other names, both jokingly and seriously. Call it whatever you like. Besides, a 
hypothetical flag with that name would be set to "yes" to *enable compatible* 
behaviour. It's the compatible behaviour that's broken, not the new one.

> I do not consider enabling the VSFilter incompatible behavior which libass 
supported in its early days many years ago, to be primarily about script 
portability. It make me sense ulterior motives for making larger changes into 
the future.

Sorry, but I honestly find it hard to make sense of these two sentences. Please 
rephrase if I misunderstand.

It doesn't matter what libass behaved like in its early days. Nobody cares, or 
at least I don't and neither do fansubbers. Making ASS make sense is about 
making ASS make sense, not about portability. Discussing changes with the 
participation of various implementers, users and interested third parties is 
about portability (as well as about usefulness).

What ulterior motives? Some completely wild guesses, hopefully all wrong: are 
you afraid that libass is aiming to somehow use the new header to take over as 
the de facto standard renderer? Why would you be worried about that, and why 
would libass developers even take part in the discussion if this was the case? 
Or maybe they're secretly planning to create a new subtitle format that will 
replace the tag^WVSFilter bug soup that is ASS? How is this even relevant, how 
is it secret and why are you supportive of such an initiative when it's called 
by a different name?

Wait. But that's all irrelevant, because both variants of the new header 
introduce VSFilter-incompatible behaviour. Just like any other new feature or 
bug fix would do. So you are not arguing against the Boolean variant but rather 
against the whole new header. I thought we all agreed that video-independent 
scaling was desirable.

> Our performance enhancements have already caused well enough user grief with 
forced updates, which has accelerated xy-VSFilter's adoption rate.

Indeed, it has accelerated it. Which means xy-VSFilter is getting to the point 
where it has enough market share to introduce more 
incompatible-with-old-VSFilter changes like new override tags. :) But we're not 
discussing such a change at the moment, and I'm not suggesting any! (Unless you 
count issue #144, which fansubbers--at least the ones I asked and got a 
response from--seemingly agree should be fixed.)

What it hasn't done is cause special grief with forced updates. Firstly, 
fansubbers keep adopting new technology all the time. Viewers need to regularly 
update their filter chains anyway, and xy-VSFilter releases already happen more 
rarely than those of video and audio decoders. There will always be people who 
don't update, but they'll encounter problems whether xy-VSFilter moves forward 
or not. Secondly, whether viewers need to update or not is the fansubbers' 
problem. If they want to let their viewers use old filters, nothing's stopping 
them--as long as it's easy enough to achieve this. When HTML is updated (which 
happens all the time now thanks to WHATWG), it's up to Web site authors to 
decide whether and how to use the new features.

In fact, while editing this post, I realized that gradually turning ASS into 
the-new-format-to-replace-ASS with incremental changes isn't a bad idea at all. 
This has been very effectively done with ASS itself with ScaledBorderAndShadow, 
and this is essentially what HTML5 is all about, and look at how wildly 
successful *that* is.

Still, let's focus on a video-resolution-independent scaling header for the 
time being.

Original comment by chortos@inbox.lv on 20 May 2013 at 4:51