ass转sup字幕工具Spp2Pgs 0.9.3.7

asxzwang

工具及简要说明】
Spp2Pgs 0.9.3.7
输入ass文件，bgra格式的avs，或者其他可播放的bgra源文件，或者来自stdin的bgra raw流
输出sup文件，或者输出到stdout
参数详见程序运行输出

运行时，%Temp%路径所在分区需要留出4G以上空间；可在执行前设置%Temp%路径，转移工作时临时文件的存储位置。
devel目录下为.net库及其它开发相关的内容；legacy目录下为基于3.0.0.306版本的xy-VSSppf

遵GPLv3许可协议发布，协议内容见源码，详见后文
耐得住一般特效；全屏动态黑板一般也能生成文件，但是为了兼容性会掉帧。
生成的sup文件严格遵照蓝光标准，因此大面积+动态的话会导致丢帧，严重程度主要与画面面积相关，请结合临床。

默认在起点处添加了“前黑”，避免字幕在大金中混流时需要手工指定起始偏移。
另可通过二次开发将多个ass文件连续合编入单一的sup文件中，参见示例代码。

项目概况】

目前项目维护地址(git)：
https://github.com/subelf/Spp2Pgs

从13年开始就断断续续地做蓝光标准相关的一些文件的解析
手上资料匮乏，也没有相关的经验，更无奈的是现有的蓝光相关的工具没几个开源的
暂时这么搞着……至少是个开源的东西，就算我扑街了还有别的盼头……

目前想法是，小文件和目录结构交给C#了，大文件里流数据的编解还是应该用C++来写，封装后再交给CLR来调用。一方面解决效率问题，另一方面也是避免一些许可协议问题。
小文件目前能处理整个mpls文件和半个clpi文件，目录结构被我写成翔了，等参考一下MGVC和3D的盘重写。
目前扔在这儿了(hg)：
https://bitbucket.org/subelf/bluraysharp

现在开始处理大文件。


外挂结构制作概况】

该项目以外挂结构的制作为重，最理想的情况当然是ass直接变外挂。
那么简述一下传统外挂结构制作的整个过程：
1. ass调轴准备，就绪后用avs挂成argb视频片段。
2. 用工具avs2bdnxml逐帧分析该片段，确定各帧图片和帧的持续时间；切除掉空白区，并适当处理后输出为xml+png；也可以输出sup文件，但是问题多多。
3. 生成的xml+png，作为bndxml，被SceanaristBD导入后，编码成pes+mui文件。其中pes存储编码后的显示图形(PG)。而mui具体含义不明，对pes来说存储的是各数据单元的时间戳信息。之后，pes+mui可以被大金用来混流形成m2ts文件，混流时的时间戳需要参考对应的视频片段。
3. sup文件，也可以直接被tsmuxer用以与音频或视频进行混流，形成m2ts文件。但是此方法可能存在兼容性问题。
4. 之后通过修改mpls文件，将字幕m2ts与视频m2ts关联起来，形成外挂结构。

整个过程中，最期望的就是2~4的完全自动化。
目前tsmuxer姑且可用，avs2bdnxml则麻烦多一些，mpls的修改目前没什么问题。大金参与的自动化则基本是不可能。
因此实现外挂字幕自动化的原则如下：
1. 最终期望可以有图形化界面。
2. 核心的代码，效率另说，可读性最重要，尤其是在体现文件结构方面。开源。
3. 先解决有无，再解决稳定性和兼容性，最后是尽量尝试替代闭源工具。

所以目前选择pes先下手，以期从ass生成可用的pgs文件成为可能。
之后再考虑pgs/sup生成m2ts的问题。


目录】

PG的基本顶层概念
PG相关的编码概念
定义：文件结构
定义：时间戳计算公式
卖萌的夏娜菊
其他细节


目前已完成的】

1. 解析从原始Epoch到pes文件的编码过程中，需要做的特殊动作：补空白段，时间戳生成等
2. avs2bdnxml的核心逻辑部分重写为C++代码，保留原有sse2汇编并稍作修改。
3. 初代：关键帧存档功能，帧剪裁+窗口区覆盖统计；色板的生成与映射算法·改；Demo v0.1, 完成视频流解析动作，捕获帧，并模拟编码pgs
4. 二代：pgs文件的编码；图形元件的编码；时间戳的统计与计算；窗口区域的判明及切割·改；pgs输出；管道输入
5. 三代：图形元件的面积优化算法；C++/CLI封装版本；去除对avs的依赖


未来已完成的】
6. 四代：避免生成临时文件；优化图元buffer使用；pes+mui的可选生成版本；
7. 五代：那么遥远的未来以我的能力看不到
8. 六代：完善文档，在这帖子卖萌，加图，加特技；验证3D盘的标准定义
使用方法：软件目录按住shift+右键选择powershell,出入命令

.\spp2pgs -i "1.ass" -s -1080 -r 23 "output.sup"

-i <filename>
                 Input subtitle file name. Use '-' for a stdin raw input.
        -s <format>
                 Frame format:
                 480i   = 1/240/-480
                 576i   = 2/288/-576
                 480p   = 3/480
                 1080i  = 4/540/-1080
                 720p   = 5/720
                 1080p  = 6/1080
                 576p   = 7/576
        -r <rate>
                 Frame rate:
                 23.976 = 1/23
                 24.0   = 2/24
                 25.0   = 3/25
                 29.97  = 4/29
                 30.0   = 5/30
                 50.0   = 6/50
                 59.94  = 7/59
                 60.0   = 8/60
        -b <frameid>
                 Beginning index of valid frames.
        -e <count>
        -n <count>
                 count of frames.
        -z[0|1]
                 Setting up an extra epoch at the very beginning or not.
                 0      = No;
                 1      = Yes;
                 (blank)= Yes. (default)
        -x[0|1]
                 Using extremely strict mode or not.
                 0      = No;
                 1      = Yes;
                 (blank)= Yes. (default)
        -v[level]
                 Output level.
                 (blank)= All, verbose;
                 63     = Errors only.
                 127    = Errors and warnings.
                 144    = Normal outputs. (default)
        <filename>
                 Output file name. Use '-' for a stdout output.

目前软件已经停更了，现在导出的字幕用在4k原盘字幕会过小，有源码，望高手接手更新下。
下载地址：链接: https://pan.baidu.com/s/12OLnfdyL-OSkeGJPk65UxQ 提取码: 3ben
https://22.gigafile.nu/0928-cbcef616288936ccdac00f93ad071d5da
github-zip链接：链接: https://pan.baidu.com/s/1lh12UdbFCdW5CnXOdlgNUw 提取码: 1a7y

asxzwang

pes与pgs中，DTS及PTS值的计算方法（伪代码）：https://bitbucket.org/snippets/subelf/5Gor/#file-GxSegTime.cpp 的备份
关于时间间隔】

1. Epoch内的版本复用问题

在某一时间点，已经进入DTS时间，尚未进入PTS时间的DisplaySet最多可以有8个。也就是说播放设备最多只需要存放8个调色板。
因此PDS的ID编号从0到7就足够了。
同理，ODS也限定了最大ID为63。
而version则可以不断更新，最大允许255。

因此，同时也要注意的是，相同ID不同版本号的PDS和ODS，在时间上不可以有重叠。否则前一DisplaySet的数据解码后尚未显示，将会被后一DisplaySet的内容覆盖掉。

2. Epoch内DisplaySet的最小时间间隔

两者间必须间隔至少1帧。除非DisplaySet只更新色板，间隔最小可以为“该Epoch的Window的解码时间”，详见9楼窗口解码时间计算公式。

3. Epoch间最小时间间隔

后者的DTS必须在前者的PTS之后。即，前者显示完、释放所有资源空间后，才可以加载后者的资源。


关于Segment内各实例的编号】

1. Composition (PCS) 这货的编号是全局的，0开始，每有一个Composition就增1，包括空白PCS。
2. Window (WDS)。在同一个Epoch内，各DisplaySet的WDS应该是相同的，包括空白PCS。理论上来说，Window的大小与位置，决定了该DisplaySet在显示前需要在缓存上擦除的区域。由于每个Epoch最多有两个Window，所以Window的编号只能是0或者1。
3. Palette (PDS)。每个DisplaySet只能使用一个Palette，而同时解码进缓存的DisplaySet最多允许8个，所以留给Palette的总空间只有8个，编号也就是0~7。通过版本号与内容的更新来满足需求数量。
色板内的每一个颜色也都有一个编号，0~255。正常来说，0是固定留给全透明的，RLE中最省编码。至于把0留给其他色，比如实际使用最多的颜色，未验证过其兼容性。
4. Object (ODS)。 每个Object的编号也是在Epoch范围内的，最多允许0~63共64个编号。同样，使用版本号与内容的同步更新来满足数量。但是更新版本时无法增加Object的尺寸。至于使用相同或更小面积的不同尺寸图片做版本替代，目前未验证过其兼容性。

asxzwang

编码】

CompositionObject使用RLE进行了压缩。算法简述：
1. 对图形的每一行进行编码，编码完成后以两个0表示行结束。各行数据的编码结果连续保存。
2. 对每行编码时，以字节为单位。对每一个字节值x，统计该字节值连续出现的次数（行程）Nx。
3. 写入RLE编码时，使用如下策略：
　a.x为0时，先写入1字节0，再写入变码后的Nx，变码规则f(Nx, 0)
　b.x为非0时，若Nx不大于2，则直接照抄1或2个x
　c.x为非0时，若Nx大于2，则先写入1字节0，再写入变码后的Nx，变码规则f(Nx, 1)，再写入x
4. 变码规则f(Nx, S)：
　a.若Nx的值较小，表示为2进制时不超过6位，则输出1字节值，低6位为Nx, 第6位为0，第7位即最高位为S；
　b.若Nx的值超过6位，则输出2字节值，低14位为Nx，第14位为1，第15位即最高位为S。字节序为大端。

asxzwang

HDMV-PGS的原始设计思路】

HDMV-PGS官方标准的制定，其核心思想有二：
1. 用来呈现字幕内容的话，一个画面上有两个带透明度信息的矩形图片就够了
2. 复杂的内存管理在编码时由强大的编码器计算规划，而播放机中的解码器只要遵照标记完成图片绘制就够了

以上二者共同决定了PGS的蛋疼。

那么，下面将从PGS的结构开始，简述一下解码和呈现过程，用来帮助理解其编码过程。

首先是结构：
PGS实际由一系列Segment组成。每个Segment有解码时间DTS，与呈现时间PTS两个时间戳。在相应时间到来时，控制器对其进行相应的处理。
PGS含有五种segment:
presentation composite segment (PCS)
a window definition segment (WDS)
a palette definition segment (PDS)
an object definition segment (ODS)
and an END segment

这些Segment的作用，是在PG缓存平面上完成一次绘制或者擦除命令。这样的一个命令称为composition。每个composition，一般由一组Segment构成。PG缓存平面就是一个含透明信息的图像缓存区，储存当前字幕图像，画面大小与视频画面相同。同样的，菜单所在平面为IG缓存平面。最终，PG、IG两平面会被依次叠加到视频上进行显示，呈现给用户。
整个过程中，Segment数据的读取、解压、转存就是解码过程；而将转存在缓存内的数据绘制到PG平面上，就是呈现过程；IG、PG、视频三平面的叠加过程则不需要关心。

然后是各种Segment的解码过程：
首先，是PCS，这是一个composition的总纲，指示有数据需要解码并呈现，PG解码器将进入工作状态。PCS向解码器报告图元的总数量，图元所在缓存的编号，图元中需要绘制的是哪一块区域，绘制时目标窗口区的编号，及相对位置，使用的色板编号。另外，如果PCS中带有EpochStart标记，播放机系统需要做相应的初始化准备，如内存分配、图像缓存平面擦除、图元和色板缓存初始化等等。此外，PCS中带有对应视频的画面尺寸及帧率等信息，提供给解码器，一般来说，一段PG流中的各个PCS内包含的这些信息应该是完全相同的。
然后是WDS，描述了使用的窗口数量，及各窗口的位置和大小。
接着是PDS，用来对调色板缓存进行更新。其中记载着调色板的编号和版本号，及若干调色板数据。如果版本号比该编号缓存的当前版本高的话，那么调色板数据会被解码器直接送入该色板缓存中进行更新。
再之后是ODS，用来对图元缓存进行更新。其中记录图元对象，也就是图片内容，同样有编号和版本号，及RLE编码后的图元数据。同样，解码器对比版本后，会将其解码成索引色图片，送入对应的图片缓冲区。ODS可能会有两个。
最后是END标记，用来指示解码工作完成，PG解码器退出工作状态。
接着又是下一个PCS。如果PCS内没有包含EpochStart标记，所有缓存区资源都会被继续使用。否则就要重新初始化所有的资源，之前的编号和版本号全部作废。
如此往复，完成一个个绘制或擦除命令的准备工作。以上就是一个composition中，各Segment的简单解码过程。

其中，图片缓存最多64个，每个缓存的大小由其存放第一个版本的图片的面积决定，而后续版本的图片尺寸需要与其一致；所有缓存的总大小不得超过4M。色板缓存最多8个，缓存大小固定不需关心。二者的版本号同样最多刷到255。
窗口和图元对象都是最多两个，窗口间不能重叠，不过两张图片可以绘制到同一个窗口区，只要不互相重叠。


下面讲一下呈现的过程：
所谓呈现，是指把解码后的资源绘制到PG缓冲平面上去，整个过程与解码同步进行。
PCS的PTS时间戳决定了该composition命令体现在屏幕上的时间，也就是实际显示时间。在PTS到来时，完成PG缓冲平面的绘制，系统将会自动将该平面叠加至视频上。

首先，遇到PCS带有EpochStart标记时，需要重新分配资源。PG平面需要重新分配后完全擦除。
然后，如果一个PCS内的图元只绘制到一个窗口中的话，可能会有一个空窗口，那么就要在PG平面上先擦除不使用的窗口区。同样，如果一个窗口内所需要绘制的图元是旧有图片，不需要更新，那么该窗口区会先被进行绘制。
其次，窗口内所有需要更新的图元，对应的ODS全部解码完成后，目标窗口就会进行绘制。
这样，PG缓存平面就绘制完成了。这些绘制和擦除实施到PG平面上后，直到下一次命令之前，画面就会一直保持不变。
而图片的擦除方法很简单，给一个带有目标时间PTS的PCS，只提供WDS描述目标窗口区域，不含任何要绘制的图元，以一个END结束。这样的一组segment就构成了一个擦除命令的Composition，将会擦除目标窗口区域。

以上就是PGS解码和呈现的基本过程。
Segment的具体数据定义可见：https://bitbucket.org/snippets/subelf/5Gor


抽象概念】

利用以上Segment元素，字幕中的各种抽象概念就构建起来了。
这部分可参照大金的PG编辑工具理解。

首先是Epoch。同一个Epoch内，含有多个DisplaySet，使用固定的一个或两个窗口区；另外，通过版本号的管理，反复使用同一套缓存资源。因为准备资源（初始化与擦除）是需要时间的，故Epoch与Epoch之间需要留有足够的时间空隙。

然后是DisplaySet。简单来说就是用来显示一次静态内容的数据集合，包含一个或两个图片，及其起始时间PTS与结束时间ETS。DisplaySet内有一个Palette，即调色板，及一到两个CompositionObject，即图片、图片所在的窗口及偏移位置信息。PTS到来时，显示图片；ETS到来时，图片显示结束。
ETS是抽象概念，实际上，ETS是靠一个空PCS进行擦除来实现的，或者下一个PCS绘制时进行覆盖来实现的（ETS与下一个DisplaySet的PTS相接时）。

所以，一个DisplaySet一般对应一个绘制Composition及一个擦除Composition；当DisplaySet连续相接时，则只对应于一个绘制Composition。

总结】

因为PG是参照DVD时代设计的，并未留出足够的冗余来容纳太多特效。最初设计时是考虑一段视频开始时，Epoch开始。出现字幕时绘制，字幕结束时擦除。出现连续字幕时连续绘制，结束时擦除。这样就能完成整个字幕显示任务。
然而加入足够多特效后，字幕占据的图像区域也不同，过多的字幕出现在同一个Epoch内，需要的窗口区将会很大，增加额外擦除开销。缓存区的管理也变得更加复杂。因此，对于ass转pgs这个目标来说，能有机会创建新Epoch时就要重新创建新的Epoch。

asxzwang

////以下是旧版本的笔记，仅供参考。

抽象概念v1】

大金提供的GUI上来看，PG的结构关系定义如下（以后都以自然语言+图片描述为主，不搞范式那些幺蛾子）：

1. Pg包含诸多Epoch
2. 每个Epoch最多拥有两个Window（窗口）
3. 每个Epoch包含诸多DisplaySet（图形集）
4. 每个DisplaySet中有一个Palette（调色板）
5. 每个DisplaySet最多拥有两个CompositionObject（元件组）
6. 每个CompositionObject是使用Object（元件）在特定的Window上，使用特定的Palette显示出的图形。

其中，Window是虚拟概念，表示显示平面上的一块矩形区域，包括左上坐标和长、宽，两个Window不可重叠。
Palette是图形所使用的颜色色板（256个y-cb-cr色，带透明度）；
Object是实际的图形，也就是一个矩阵，存储每个像素引用的色板索引。
CompositionObject定义时，需要指定引用的Object、Window，及该Object显示时其所属的Window和相对位置；
两个CompositionObject可以使用相同的Window, 但是CompositionObject显示时不允许重叠或溢出；

各个CompositionObject、Palette、Window被定义后
通过引用、指定位置完成DisplaySet中各个Composition的显示
等到下一个DisplaySet出现时，当前DisplaySet停止显示
这就是PG的基本的思想


文件结构概念v1】

pgs(sup)和pes文件之间的区别
pgs是pes加上包头之后形成的数据流
pgs每包数据以'PG'开头,携带PTS和DTS两个时间戳。包的内容为一个segment。
而pes则是全由一个个segment组成。

因此先抛开PTS和DTS，研究pes的格式。
PES含有五种segment:
presentation composite segment (PCS)
a window definition segment (WDS)
a palette definition segment (PDS)
an object definition segment (ODS)
and an END segment
每一个DisplaySet的内容实际都是以这五种segment构造出来的。

其中，ODS分段存储着图片的数据
就目前看，大金对图片的索引矩阵做了RLE压缩
之后再分段写为多个ODS
具体定义见：https://bitbucket.org/snippets/subelf/5Gor
后续回复中将做备份

与pgs不同，pes内不含时间戳信息，而是记录在MUI文件中
除去文件头，MUI中循环放置每个segment的信息：
8位 segment类型
32位 segment总长度
33位 DTS
33位 PTS
6位 补0


PGS的原初设计思路v1】

PGS在初步设计时的思路是这样的……
每段video clip对应（一般为一个m2ts）对应一个Epoch
每个Epoch里最多两个Window，也就一个主字幕区，一个副字幕区
播放设备为Epoch预留4M大小的显示缓存，用以存储解码后的图像数据
还有8个可以存储色板的区域以及一些其他缓存，最多允许缓存8帧画面
被解码的数据在解码后会被一个接一个地存储进缓存内
到了显示的时候，从缓存中读取，绘制到对应的窗口中去
这块缓存中的数据在Epoch结束后才会释放

图像显示和停止显示的时间都是由PTS来控制的。
一个DisplaySet开始时，由其PTS来确定时间。
而它停止显示，则由下一个DisplaySet来确定。
因此，当后续没有连续内容时，需要空的DisplaySet来结束一个DisplaySet的显示。

为了防止内存和编号不够用，对调色板和图像元件又提出了版本更新机制
即，后出现的PDS可以考虑和之前PDS使用相同的ID，播放设备将其覆盖到之前同ID的废弃调色板上，而版本号加1。以此节约内存的使用
同理，后出现的ODS可以使用与之前ODS相同的ID。但是为了避免内存的空洞和覆盖问题，大金只允许相同长、宽的ODS画面做更新替换。这也解释了等面积图片序列更不容易超过缓存限制的原因。
PDS的ID取值范围是0~7，ODS的ID取值范围是0~63，也就是说内存里始终只有8个色板可用，64张图形可用，需要重复利用来完成整个Epoch中各DisplaySet的显示；到Epoch结束时，一次性释放所有的资源。
版本更新时版本号要递增，而版本号的存储空间只有1字节，因此上限255。
因此，理论上能用的最大绘图空间是4M x 256，也就是1G。
但是实际使用中并不容易使用版本更新的机制来节约空间。
所以，“难用”导致了缓存还是比较容易被耗尽的。

如果没有有效手段管理缓存的复用，可以考虑适当地分割出多个Epoch，来满足使用。
只不过这一手段有违pgs的设计初衷。
目前生成的bdnxml，只要字幕不是完全连续，导入时都会被大金分割成多个Epoch。
因此，一般只有在出现大面积画面+连续面积变化画面时才会导致缓存不足报错。

asxzwang

v0.9.3.5 (@20160504)

* 更新VSFilter版本为xy-VSFilter 3.1.0.746
* 优化，小于三帧的画面将不进行分析直接绘制，缩减程序运行时间

======

Spp2Pgs 0.9.3.5

可执行程序，输入ass等字幕文件，生成sup字幕。

内包含Pgs2Pes，用于将Pgs/Sup字幕转化为大金可识别的pes+mui文件。
以及Pes2Pgs用于逆向转换。

======

Spp2PgsNet 0.9.3.5

二次开发包，面向.NET平台。
内含C#范例代码。

======

Spp2Pgs 0.9.2.15

基于xy-VSFilter 3.0.0.306稳定版本的多合一包(不含Pgs2Pes)

hyb9373

完全看不懂，好牛的样子，佩服

asxzwang

Spp2Pgs
将一般字幕转换为HDMV PG流。
换句话说，将.ass文件转换为.sup文件。

该项目生成一个命令行应用程序和一个CLR DLL文件。
它们的核心是一个静态库libspp2pgs。

引入外部dll xy-VSSppf来处理字幕文件。
它基于xy-VSFilter的分叉版本，以更简单的方式呈现和提供字幕。

这是所有四个部分的简洁描述。

Spp2Pgs的* .exe
可执行文件将字幕转换为.sup文件。
用法：
Spp2Pgs -i "X:\Saya1011con.ass" -s 1080 -r 23 "X:\Saya1011con.sup"
输入Spp2Pgs -h以获得更多帮助。

libspp2pgs和Spp2PgsNet * .dll
.NET框架应用程序的核心及其CLR库包装器。
三个班级扮演主要角色：

PgsEncoder，编码和写入pgs文件。
FrameStream，读取字幕并将字幕渲染成图像。
Spp2Pgs，所有其他东西的入口。还从FrameStream读取图像并将它们发送到PgsEncoder。
XY-VSSppf * .DLL
xy-VobSub SubPicProvider Factory。这是一个COM DLL，向Spp2Pgs公开了一个ISubPicProviderAlfa接口。
这是Spp2Pgs的必要部分。

hljwsq

好长的教程，欢迎发布

枫香秋舞

这种有什么意义吗，ass转SUP有很简单的方法

hatsukoi

枫香秋舞 发表于 19-9-15 09:41
这种有什么意义吗，ass转SUP有很简单的方法

这个工具会根据字幕动态的强度自动调整帧率从而符合大金规范。

xishan

hatsukoi 发表于 19-9-15 10:04
这个工具会根据字幕动态的强度自动调整帧率从而符合大金规范。

请问是不用过水了，然后原盘DIY可以直接用了？

meitp

xishan 发表于 19-9-25 13:34
请问是不用过水了，然后原盘DIY可以直接用了？

特效超标的ass字幕，用Spp2Pgs 生成pes会自动精简特效，可以直接导入大金。

drw

看起来很专业啊。

peony

高手中的高手，厉害。

令狐冲2019

听说不支持卡拉OK模板？？？？？

bluestar

看不懂太深奥了

masaihuiche

牛皮牛皮

whitesir

是有点高深，现在还真的看不懂，我们是外行，跟在大师后面，多少也慢慢的学些个皮毛，可以吓人的

susan香香

用了下，好用啊，ASS的特效效果显示接近完美。
SUP
ASS