AssRender: inappropriately named libass-based subtitles renderer

[real.finder]

thank you for this plugin

I wonder how can I compile lachs0r c-plugin one and what I need for that

I didn't do any plugin compile before so I need your help

I plan to play with libass and I think AssRender is a good choice for that and to releasing AssRender with last libass

[TheFluff]

If you've never compiled a plugin before, AssRender is probably the single worst example to start with. You can't actually build the plugin itself until you've compiled libass with MinGW, and that's a gigantic pain since it has a billion annoying dependencies, many of which are very tricky to get to compile on Windows. Start with something else.

[real.finder]

If you've never compiled a plugin before, AssRender is probably the single worst example to start with. You can't actually build the plugin itself until you've compiled libass with MinGW, and that's a gigantic pain since it has a billion annoying dependencies, many of which are very tricky to get to compile on Windows. Start with something else.

any suggestion?

I chose AssRender because it's just a plugin, as I can see the full program like vlc or mpv which using libass will be harder

and AssRender easy to view the subtitle file with it every time in just avspmod

[Reel.Deel]

Sorry to revive this thread, but has anyone come across binaries for the updated AssRender (v0.28): https://github.com/pingplug/assrender

I've searched and came up empty handed, most I found was a fork of the v0.28 version here: https://github.com/vadosnaprimer/assrender

But still no binaries :(

[real.finder]

Sorry to revive this thread, but has anyone come across binaries for the updated AssRender (v0.28): https://github.com/pingplug/assrender

I've searched and came up empty handed, most I found was a fork of the v0.28 version here: https://github.com/vadosnaprimer/assrender

But still no binaries :(

I tried and seems I did build x86 one https://github.com/realfinder/assrender

the x64 give me some errors in Visual Studio 2019, also the x86 I did seems only work in avs+! is the avs+ c header not work with avs 2.6 unlike the c++ one?

[pinterf]

also the x86 I did seems only work in avs+! is the avs+ c header not work with avs 2.6 unlike the c++ one?
I'd need some more hints. Does not work = crash?

On the other hand, based on https://github.com/vadosnaprimer/assrender I have successfully built both x86 and x64 (after some path fixes).

[real.finder]

I'd need some more hints. Does not work = crash?

On the other hand, based on https://github.com/vadosnaprimer/assrender I have successfully built both x86 and x64 (after some path fixes).

I got this
https://i.postimg.cc/XqnMKmvm/Untitled.png (https://postimages.org/)

and can you share your edit of the code? with the x64 built :)

anyway, at least in the built I did libass in not uptodate in the code, and maybe the others too, I didn't try to update it yet

[pinterf]

It must be because of 32 bit 'decorated' names:
Avisynth 2.6 is looking for
avisynth_c_plugin_init@4 or avisynth_c_plugin_init
Avisynth+ is looking for
_avisynth_c_plugin_init@4 or avisynth_c_plugin_init@4
When Visual Studio is compiling, it always decorates names with leading _ because of stdcall
https://docs.microsoft.com/en-us/cpp/build/reference/decorated-names?view=msvc-160

So it won't be found by Avisynth 2.6 loader.

I remember a similar case (I hope I find it soon; C plugins are rare on my git). I'll be back.

As for the code edit: I've just cloned and not forked, it's only my local disk; but practically I didn't change the code.

[pinterf]

It must be because of 32 bit 'decorated' names:
Avisynth 2.6 is looking for
avisynth_c_plugin_init@4 or avisynth_c_plugin_init
Avisynth+ is looking for
_avisynth_c_plugin_init@4 or avisynth_c_plugin_init@4
When Visual Studio is compiling, it always decorates names with leading _ because of stdcall
https://docs.microsoft.com/en-us/cpp/build/reference/decorated-names?view=msvc-160

So it won't be found by Avisynth 2.6 loader.

I remember a similar case (I hope I find it soon; C plugins are rare on my git). I'll be back.
EDIT:
Yes, it was AvsInPaint. A definition file "assrender.def" must be created with the following content:
LIBRARY assrender
EXPORTS
avisynth_c_plugin_init@4 = _avisynth_c_plugin_init@4

Only for x86-32!

As for the code edit: I've just cloned and not forked, it's only my local disk; but practically I didn't change the code.

[pinterf]

Do you wish to do that or I can arrange it on my git?
I wonder if it can be ported to Linux as well?

[real.finder]

Do you wish to do that or I can arrange it on my git?
I wonder if it can be ported to Linux as well?

if you have a time then indeed you can do it better than me :) I am not a programmer in first place

it should work in Linux and any non windows os, libass and others are not made for windows in first place

[qyot27]

I had had some intention to get builds running on this at some point, but other stuff just kept getting in the way.

RE: Linux, etc., I mean, the CMakeLists.txt is right there and it shouldn't be *too* difficult, but I can't remember the exact details. One piece of it is that that other branch with all the *.vcxproj cruft and submodules and a local avisynth.lib is totally unnecessary; I'd argue it's even unnecessary on/for Windows (especially since "C plugin" is supposed to mean GCC is probably the preferred compiler, not MSVC), but it's 1000% unnecessary on non-Windows.

[pinterf]

I had had some intention to get builds running on this at some point, but other stuff just kept getting in the way.

RE: Linux, etc., I mean, the CMakeLists.txt is right there and it shouldn't be *too* difficult, but I can't remember the exact details. One piece of it is that that other branch with all the *.vcxproj cruft and submodules and a local avisynth.lib is totally unnecessary; I'd argue it's even unnecessary on/for Windows (especially since "C plugin" is supposed to mean GCC is probably the preferred compiler, not MSVC), but it's 1000% unnecessary on non-Windows.
I've got completely zero knowledge on libass and its history.
So, qyot27, what you call the 'other branch' (vadosnaprimer) is the one dealing with submodules and introduced msvc (2015 at that time) support. The older one (pingplus) is just telling CMake to find libass and use.
https://github.com/pingplug/assrender/blob/master/src/CMakeLists.txt
Do you mean tha on Linux the old one is preferred, while on windows/msvc the vadosnaprimer one?

[qyot27]

No. I mean that the proper course of action is to correctly use CMake for all platforms. There aren't any code changes on the Blitzker/vadosnaprimer repo at all (save for one that seems pretty hacky (https://github.com/vadosnaprimer/assrender/commit/5635baa08a6bdad4291f2f6791643572ab6d0b0d); you can see this by just running git whatchanged -15 and looking at what files got touched) - it's all just the addition of MSVC project files, and changes to the README. Basically, if it's necessary, cherry-pick that one header change into the pingplug repo, ignore everything else, and flesh out the CMakeLists.txt instead.

As far as libass and its dependency chain goes, I've been dealing with that for 7 or 8 years as a prerequisite for mpv builds. As TheFluff mentioned way back on page 1, it's largely assumed you're compiling those with MinGW-w64 anyway, which is exactly what the mpv build guide (https://github.com/qyot27/mpv/blob/extra-new/DOCS/crosscompile-mingw-tedious.txt) has covered*. Most of the other commonly-used tool build systems on Windows (media autobuild suite or possibly just regular MSys2) would essentially be doing the same things and users wouldn't need submodules for anything.

*lines 412-1516 (for the zlib...fontconfig stuff) and then lines 4543-4605 for libass itself.

[pinterf]

Actually the linux part is built using existing libass 0.14 on my Ubuntu 19.10 WSL. I'm still a beginner, well I need to reference avisynth_c.h and avs/* files.
What is the best practice? Include it in the project (as now) or use the one in \usr\local\include\avisynth\ ? If latter, how can I tell cmake that directory reference? $???

[pinterf]

Actually the linux part is built using existing libass 0.14 on my Ubuntu 19.10 WSL. I'm still a beginner, well I need to reference avisynth_c.h and avs/* files.
What is the best practice? Include it in the project (as now) or use the one in \usr\local\include\avisynth\ ? If latter, how can I tell cmake that directory reference? $???
EDIT: linux, windows+msys2-mingw, windows msvc works. Cleanup is needed now after the experiments and check again if my build instructions really work.

EDIT: this is where I got finally. https://github.com/pinterf/assrender
Check README.md and feel free to correct it.
EDIT: new build 0.29 (https://api.github.com/repos/pinterf/assrender/releases)

[real.finder]

EDIT: new build 0.29 (https://github.com/pinterf/assrender/releases)

thanks, it seems work no problem now

[qyot27]

Actually the linux part is built using existing libass 0.14 on my Ubuntu 19.10 WSL. I'm still a beginner, well I need to reference avisynth_c.h and avs/* files.
What is the best practice? Include it in the project (as now) or use the one in \usr\local\include\avisynth\ ? If latter, how can I tell cmake that directory reference? $???
You can use pkg-config to detect AviSynth+ as well, since the .pc file gets generated and installed too¹.

The thing I wonder about is if linking a C-plugin to a MinGW-built libavisynth.dll.a import library will cause problems with a MSVC-built AviSynth+ host. My gut reaction says that it would be a problem, but I also wouldn't be surprised if it's okay on 64-bit but not 32-bit. The FFMS2 C-plugin is no use here; it uses LoadLibrary to communicate with the host AviSynth, so it doesn't link to anything except the FFmpeg libraries and extra libraries therein (zlib, bz2, etc.).

¹in WSL:
qyot27@cappuccino:/mnt/c/Windows/system32$ pkg-config --cflags --libs avisynth
-I/usr/local/include/avisynth -L/usr/local/lib -lavisynth

[qyot27]

While it built on Linux, I hit a roadblock when trying to actually use it. Turns out it's not linking to libavisynth, so it can't find the right API calls.

Very rough sketch (I didn't try to do any OS guarding, and requiring 3.7.0 is probably excessive):
diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt
index 7a4569f..6ad2d63 100644
--- a/src/CMakeLists.txt
+++ b/src/CMakeLists.txt
@@ -38,10 +38,12 @@ IF (NOT WIN32 OR MINGW)
FIND_PACKAGE(PkgConfig REQUIRED)
PKG_CHECK_MODULES(LIBASS REQUIRED libass>=0.12.0)
target_include_directories(${PluginName} PRIVATE ${LIBASS_INCLUDE_DIR})
+ PKG_CHECK_MODULES(AVISYNTH REQUIRED avisynth>=3.7.0)
+ target_include_directories(${PluginName} PRIVATE ${AVISYNTH_INCLUDE_DIR})
ENDIF()

#dedicated include dir for avisynth.h
-target_include_directories(${ProjectName} PUBLIC ${CMAKE_CURRENT_SOURCE_DIR}/include)
+#target_include_directories(${ProjectName} PUBLIC ${CMAKE_CURRENT_SOURCE_DIR}/include)

if (WIN32)
# avisynth.lib for C API
@@ -57,7 +59,7 @@ if (WIN32)
TARGET_LINK_LIBRARIES(${ProjectName} ${AVS_LIBDIR}/avisynth.lib)
endif()
else()
- TARGET_LINK_LIBRARIES(${ProjectName} ${LIBASS_LDFLAGS} )
+ TARGET_LINK_LIBRARIES(${ProjectName} ${AVISYNTH_LDFLAGS} ${LIBASS_LDFLAGS} )
endif()

include(GNUInstallDirs)
diff --git a/src/assrender.h b/src/assrender.h
index 23c154e..f63bf94 100644
--- a/src/assrender.h
+++ b/src/assrender.h
@@ -6,7 +6,7 @@
#include <math.h>
#include <string.h>
#include <ass/ass.h>
-#include "avisynth_c.h"
+#include <avisynth/avisynth_c.h>

#if defined(_MSC_VER)
#define __NO_ISOCEXT


With the above, it also works on Linux as well, with the obvious caveat that AssRender hasn't yet been updated to support high bit depth, so the 10-bit test file I had lying around needed ConvertBits(8) before handing it over to AssRender. But it was certainly able to load the styled karaoke subtitles and even load the font used by specifying the fontdir= parameter (although since the font was Ubuntu Regular and I was testing under Ubuntu, that was a pointless test).

[real.finder]

and even load the font used by specifying the fontdir= parameter (although since the font was Ubuntu Regular and I was testing under Ubuntu, that was a pointless test).

speaking of fonts, the "testing sub file" here https://github.com/libass/libass/issues/148#issuecomment-780239346 has font (Attached) inside the .ass file, vsfilter load it ok as it should, but assrender didn't load it unless using fontdir= to folder has the font (didn't try to install the font in the system), is it problem in assrender or libass itself?

[qyot27]

I wouldn't know; the prevailing norm is typically not to embed fonts directly in the subtitle file, as issues with that come up sometimes on mpv's bug tracker. So I assume it's probably in libass itself.

[real.finder]

seems colorspace in assrender is wrong

using ctest.avi https://www.solidfiles.com/v/nDrqzLnrLAmrz and https://www.solidfiles.com/v/7GnWRwwrXyYkY

vsfilter:- (also same as no using anything)
https://i.postimg.cc/hJNRRtVX/vs.png (https://postimg.cc/hJNRRtVX)
work as it should it's not, its same as the 3rd image, vsfilter not work with yv24 and will do nothing if it used with yv24

assrender:-
https://i.postimg.cc/Vd4yLRjQ/la.png (https://postimg.cc/Vd4yLRjQ)
all wrong

assrender with setting colorspace = "Rec601":-
https://i.postimg.cc/BjXJryRw/la-6.png (https://postimg.cc/BjXJryRw)
almost ok, still not as perfect as vsfilter, maybe this libass problem not assrender
it's not libass one as Kainote (aegisub don't like libass and crash on me in many cases) with libass work ok edit: vsfilter show similar output

For historical reasons, if .ass file not has "YCbCr Matrix:" info then it should be treated as it "Rec601" to maintain compatibility, and seems assrender use Rec709 in this case

[real.finder]

I wouldn't know; the prevailing norm is typically not to embed fonts directly in the subtitle file, as issues with that come up sometimes on mpv's bug tracker. So I assume it's probably in libass itself.

I did try it and it seems work ok in mpv!

https://i.postimg.cc/QKVr2YMq/Annotation-2021-02-17-083749.png (https://postimg.cc/QKVr2YMq)

[pinterf]

What should be the default fontdir in non-Windows environment?

Now the parameter is set to "C:/Windows/Fonts" which is obviously not the best choice for linux.

[real.finder]

What should be the default fontdir in non-Windows environment?

Now the parameter is set to "C:/Windows/Fonts" which is obviously not the best choice for linux.

it's not the best choice even for Windows now (there are some win10 update added new fonts folder per user)

[qyot27]

What should be the default fontdir in non-Windows environment?

Now the parameter is set to "C:/Windows/Fonts" which is obviously not the best choice for linux.
Typically I believe it tends to be /usr/share/fonts. But fontconfig means that it probably should just be reading the result of fc-cache.

[pinterf]

Meanwhile you can try 0.30.
All colorspaces are supported up to 16 bits.
Incl. YV411, RGB48/64 and planar RGB.

[FranceBB]

0.30 works fine on Windows XP in 16bit and the best part is that I can finally hardsub at high bit depth without doing this:

s16 = last
DitherPost (mode=-1)
TextSub("subs.ass")

#Overlay 8bit subs to 16bit video
Dither_convert_8_to_16 ()
s16.Dither_limit_dif16 (last, thr=1.0, elast=2.0)

#Output 16bit interleaved to avs4x265.exe -> x265.
Dither_Out()

as I can just do this:

AssRender("subs.ass")

in 16bit planar. :D
I don't know why AssRender works just fine on XP and VSFilter doesn't, but this way I can finally work in regular planar high bit depth and I'm thrilled! :D

[StainlessS]

Some versions of VSFilter are a bit dodgy, not sure if particularly error laden on XP or not.

[pinterf]

And a semi-final (there is no such word as 'final') bugfix release.
Planar RGB colors were khhm.. not really perfect*.

v0.31:
https://github.com/pinterf/assrender/releases/

*channels mixed. Could not recognized on FF FF FF full black text color.

Important note: by introducing high bit depth, Avisynth 2.6 classic is not supported anymore. This is a C plugin, we cannot be smart.
For this reason release pack contains v0.29 which is happily running with old avs 2.6.0.5.

[DTL]

What glyph render engine do it uses ? It looks do not take any care about conditioning for video systems and its output cause awful alising and ringing. May be usable only at final digital display resolution without scaling.

If it can output xxxA format with alpha channel for blending the immediate processing may be applied like GaussResize(width/2,height/2, p=20) (to the double sized rendered text). But it is better to make processing internally in the filter. Like applying FSAA by shrinking with appropriate core Avisynth resamplers with a given 'AA-quality' ratio. 2x already do a good work.

My test script:

LoadPlugin("assrender.dll")
BlankClip(1000,2000,1000, pixel_type="YV12", color=color_gray30)

assrender(last, "srt01.srt", srt_font="Wolfgang Amadeus Mozart", scale=2, bottom=-500)

GaussResize(width/2,height/2, p=20)

SincResize(width*2, height*2,taps=8)

srt.txt listing
1
00:00:00,498 --> 00:00:02,827
- Sample text for testing


If remove GaussResize(width/2,height/2, p=20) the output looks significally distorted.

[qyot27]

FreeType.

https://mrandri19.github.io/2019/07/24/modern-text-rendering-linux-overview.html

Although all the video players I know of that use libass always overlay the subs as the final step in the chain.

And there's also the part where the filter is designed for a subtitle format that's far more configurable than SRT.

[DTL]

FreeType looks typical PC-screen glyph rendering engine.

Avisynth typically used for processing from file to file with unknown target digital display pixel count (really for moving pictures non-pixel based displays at all). So it is good at text render sources at least to have an option for creating more compatible with 'moving pictures' video systems images data.

Same applied to core Avisynth text renders like 'Subtitle' filter, but I think it mostly used for tech debugging purposes not for real high quality production.

If the text string of glyphs is rendered inside external to plugin library so the only option is post-process the whole subtitle text image. But it must be done before blending to output.

May be at least add option for output non-blended with alpha subtitle render result for external post-processing inside scripting like:

LoadPlugin("assrender.dll")
src=BlankClip(1000,2000,1000, pixel_type="YV12", color=color_gray30)

dummy_x2=PointResize(src, src.width*2, src.height*2)

srt_layer=assrender(dummy_x2, "srt01.srt")

srt_layer=GaussResize(srt_layer,width/2,height/2, p=20) # or any other MyLovelyFSAADownscaler(...)

Overlay(src, srt_layer)


It will be a bit less performance because downscaler will process whole 2x frame buf insead of only subitle area, but full working workaround.

[Reel.Deel]

And a semi-final (there is no such word as 'final') bugfix release.
Planar RGB colors were khhm.. not really perfect*.

v0.31:
https://github.com/pinterf/assrender/releases/


:thanks: Thank you for all that you do pinterf! I updated the wiki already, I see that every now and then you beat me to it, shame on me :)

[real.finder]

seems colorspace in assrender is wrong

using ctest.avi https://www.solidfiles.com/v/nDrqzLnrLAmrz and https://www.solidfiles.com/v/7GnWRwwrXyYkY

vsfilter:- (also same as no using anything)
https://i.postimg.cc/hJNRRtVX/vs.png (https://postimg.cc/hJNRRtVX)
work as it should

assrender:-
https://i.postimg.cc/Vd4yLRjQ/la.png (https://postimg.cc/Vd4yLRjQ)
all wrong

assrender with setting colorspace = "Rec601":-
https://i.postimg.cc/BjXJryRw/la-6.png (https://postimg.cc/BjXJryRw)
almost ok, still not as perfect as vsfilter, maybe this libass problem not assrender
it's not libass one as Kainote (aegisub don't like libass and crash on me in many cases) with libass work ok

For historical reasons, if .ass file not has "YCbCr Matrix:" info then it should be treated as it "Rec601" to maintain compatibility, and seems assrender use Rec709 in this case

another test file but it has YCbCr Matrix info in it https://github.com/pinterf/assrender/files/6056802/ctest2.zip

it show similar output to
https://i.postimg.cc/BjXJryRw/la-6.png (https://postimg.cc/BjXJryRw)

again no problem in vsfiler family (TextSub)

edit: I did a test for SD (Rec601)

https://github.com/pinterf/assrender/files/6056968/ctest.SD.avi.zip

https://github.com/pinterf/assrender/files/6056969/ctest.SD.sub.zip

https://github.com/pinterf/assrender/files/6056971/ctest.SD.sub.with.info.zip

and it seems work fine! so the problem happen when the video is HD

[pinterf]

Manually recalculated the applied rgb2yuv (709) matrix coefficients and there really is a miscalculation.
edit: please check this one: https://github.com/pinterf/assrender/releases/tag/0.33

[real.finder]

Manually recalculated the applied rgb2yuv (709) matrix coefficients and there really is a miscalculation.
edit: please check this one: https://github.com/pinterf/assrender/releases/tag/0.33

it's kinda better but still not fixed, I think it should copy how vsfilter do it

[pinterf]

Apart from this 709 matrix coefficient typo, have you read the readme that the default color space is governed by video dimensions?

`string colorspace`

The color space of your (YUV) video. Possible values:
- Rec2020, BT.2020
- Rec709, BT.709
- Rec601, BT.601

Default is to use the ASS script’s “Video Colorspace” property, else guess based on video resolution (width > 1920 or height > 1080 → BT.2020, then width > 1280 or height > 576 → BT.709).


This script is o.k.
AviSource("ctest.avi").Info()
ConvertToRGB("rec601")
ConvertToYV12(matrix="rec709")
AssRender("ctest.ass") # treats HD (>=1280x720) as BT.709

[pinterf]

My latest fix for coeff was not valid. Either I have found a wrong source for coeffs on the Internet or had bad eyes when I was copying. Anyway I have reverted that change back and now wait a bit.

[Reel.Deel]

Apart from this 709 matrix coefficient typo, have you read the readme that the default color space is governed by video dimensions?

I think what real.finder is trying to say is that ASSFilter should behave like VSFilter. Long ago before HD, Aesgisub and VSfilter treated everything as BT.601. This issue has been discussed in this thread already and was concluded that ASSFilter should move away from legacy crap and keep doing things as they are.... I agree. If someone cares so much about legacy things they should use legacy VSFilter. Also, until now, there weren't any x64 binaries available so I don't think this filter was used much by people, just my guess.


To emulate vsfilter behavior...
…is not the point of this feature. The point is to use the *correct* color matrix (i.e. the one used by Aegisub) for overlaying the subtitles.

It would eliminate the issue entirely if there were no legacy subtitles out there; but there are oodles of ass/ssa scripts that choose subtitle colors to match the video and assume vsfilter behaviour when doing so.
Easy solution: Forget legacy subtitles and move along. There’s no reason to give ourselves more trouble than necessary over old subtitle files.
The problem with those files is just that they always assume BT.601 colorspace, since Aegisub made the same mistake for a very long time.
Playback software that gives a shit would just have to convert the colors for files which do not have the Video Colorspace property.

Some history on this issue:

https://github.com/dreamer2908/Aegisub_automation_scripts#ass-color-matrix-converter

https://guideencodemoe-mkdocs.readthedocs.io/typesetting/aegisub/#the-subtitles-provider


Edit:
Tool to change color matrix on ASS subtitles: ASSColorMatrixConverter (https://www.dropbox.com/s/n02xbdo904h1cw7/ASSColorMatrixConverter_beta9.7z)

[real.finder]

I think what real.finder is trying to say is that ASSFilter should behave like VSFilter. Long ago before HD, Aesgisub and VSfilter treated everything as BT.601

yes, even mpv and libass try keep VSFilter compatibility (mpv play those sample as they should), I still don't use libass things myself cuz there are some "not fixed yet" issues in libass since 2014!

anyway, VSfilter should work with other than BT.601 too if it set in the .ass file but still ASSFilter not behave like VSFilter

have you read the readme that the default color space is governed by video dimensions?

yes I know, but ctest2.ass (https://github.com/pinterf/assrender/files/6056802/ctest2.zip) should work as it since it BT.709 but it's give similar output to

https://i.postimg.cc/BjXJryRw/la-6.png (https://postimg.cc/BjXJryRw)

AviSource("ctest.avi").Info()
ConvertToRGB("rec601")
ConvertToYV12(matrix="rec709")
AssRender("ctest.ass") # treats HD (>=1280x720) as BT.709

yes that ok :) but it do unnecessary conversion for colors, but I think it's ok for debugging purposes

[pinterf]

assrender seeks for
Video Colorspace:
but the .ass file is using
YCbCr Matrix:

e.g.
YCbCr Matrix: tv.709

Since the .ass file does not contain "Video Colorspace:" section, it does nothing.

I suppose assrender filter should detect "YCbCr Matrix:" isn't it?

[pinterf]

Next iteration v0.34:
https://github.com/pinterf/assrender/releases/tag/0.34

[real.finder]

assrender seeks for
Video Colorspace:
but the .ass file is using
YCbCr Matrix:

e.g.
YCbCr Matrix: tv.709

Since the .ass file does not contain "Video Colorspace:" section, it does nothing.

I suppose assrender filter should detect "YCbCr Matrix:" isn't it?

yes, that what I fix here https://github.com/pinterf/assrender/pull/2

but still the HD Video colors problem not fixed (but it get better as I said back then https://forum.doom9.org/showthread.php?p=1936112#post1936112 3rd image)

[pinterf]

Oh, I didn't recognized that PR, no notification received.

[pinterf]

I still cannot see any difference between the 1st and 3rd image.

[pinterf]

Does anyone use less-than-HD in 2021? Why should it behave in tv.601 by default?

[real.finder]

I still cannot see any difference between the 1st and 3rd image.

it's kinda hard to note yes, the yellow and green bar has no difference, you can let Histogram("luma") help you for luma but there are difference in chroma too

[real.finder]

Does anyone use less-than-HD in 2021? Why should it behave in tv.601 by default?

in case of old subtitles (2012 and down), they were with no YCbCr Matrix: info, new ones should already has YCbCr Matrix with tv.709

[pinterf]

So in the past 8 years subtitles are directly specifying the matrix. And if it's not specified directly, it is safe to say that they are 601?