一个针对日本的数字电视应用（ISDBT）里字幕处理有一些问题，规范文档庞大又复杂，读起来还觉得语焉不详。接手遗留项目尝试处理字幕显示的问题，边读spec边看代码，先猜测、试图理解既有逻辑，再分析问题产生的原因，寻找解决方案。
文档是ARIB STD-B24 Version 5.1 Volume 1(Data Coding and Transmission Specification for Digital Broadcasting)。文档中出现的"02/0"表示0x20，“07/15"表示0x7F。
1. 一个data group里的多个data unit
按照规范文档定义（见文档的Table 9-1
Data group），一个字幕数据（one caption data）最多由256个data groups组成。data
group结构里有6位的group id，2位的group version，8位的group link number（从0开始），8位的last
group link number（标明最后一个group）。但实际上绝少见到一个data
group放不下的字幕数据。目前的实现只考虑了一个data group。
根据group id，group可以分为caption management group和caption statement group（见文档的Table 9-2 Correspondence to caption data and data group identification），这两类data group结构都在最后包含了若干个data unit（见文档的Table 9-3 Structure management data和Table 9-10 Caption statement data）。
观察码流发现，大部分情况一个data group里只有一个data unit，但还是不止一次地看到同一个data group里有两个data unit。出现这种情况时，第一个data unit都是0x0C开始、包含字体大小、颜色和字符编码的数据（data unit的不同类型参见文档的Table 9-12 Types of data unit，这里只讨论0x20，即statement body），第二个data unit都是一个TIME命令（9D 20 XX 0C，这里是十六进制表示，下同）。之前的实现假设一个data group里如果有多个data unit，每个data unit也都是0x0C开始、包含字体大小、颜色和字符编码的数据，如果只有命令而没有字符编码数据则会被丢弃。
怎么理解只有TIME命令的data unit？目前只能认为是补充前一条data unit（0x0C开始、包含字体大小、颜色和字符编码的数据）。
观察码流还发现另一种情形，data group里只有一个data unit，这个data unit的数据也只有一个0x0C。前面一直没有提到0C命令，这里讨论一下。在文档的Table 7-14 Control function character set code table中可以看到，0C是清屏命令（CS），Table 7-15 C0 control set中定义为“Display area of the display screen is erased”。在之前的实现里，没有字符数据的data unit都被丢弃了。可是为什么会送出一个单独的0x0C呢？在某一个码流里还看到连续两个这样的data group，只有一个data unit，里面只有一个0x0C。
根据0C的定义，我们可以这样理解每一个包含字符数据的data unit，0x0C开头意即清除上一条字幕，开始准备显示当前字幕。TIME命令后如果跟随0x0C（9D 20 XX 0C），意即presentation了duration的时间后清除（TIME命令的分析见下文）。单独的一个0x0C是不是意味着，没有要显示的字 幕，但也要清除上一条字幕呢？目前只能这样去实现了。
2. caption management group中是否有DC
通过解析
DMF（display mode）来判断DMF之后是否有一个单字节的DC（display condition
designation）（见文档的Table 9-3 Structure management data），文档的Table 9-5
Display mode和Table 9-6 Designation of display
condition解释了DMF和DC，可还是没看懂DC。观察码流，DMF的值总是10（十进制），按照规范文档定义，DMF等于12、13或14时，
后一个字节是DC。
3. TIME命令
按照文档“ARIB STD-B24 Version 5.1 Volume
1”的解释，9D是TIME命令（见文档的Table 7-14 Control function character set code
table），在Table 7-16 C1 control set中定义了三种情况，观察测试用的一些码流，情况（1）最常见，即"TIME
02/0 P2”，情况（5）“TIME 02/8 P2"和情况（6）“TIME
02/9"不多见，这里只分析情况（1）。三种情况的解释请见下面的注释代码段。
“TIME 02/0 P2"的命令模式意味着遇到9D 20 XX这个模式，取出XX的低6位作为P2，P2设置字幕显示的duration时间，单位是0.1秒，取值范围是从0x40到0x7F。
观察实际的码流，最常见到的命令模式是9D 20 XX 0C。也比较好理解，即当前字幕显示P2/10.0秒之后清屏。之前的实现把0C作为该模式之必要。
可是，在某一个码流里发现这样的情况：9D 20 7F 9D 20 7F 9D 20 7F 9D 20 44 0C。按照之前的处理逻辑，第一组9D 20的P2后不是0C，于是放弃把9D当作TIME命令来处理，跳过9D，继续解析20和7F（20会被作为空格处理，7F本是删除，这里忽略不作处 理），直到最后一个9D，能找到那个0C，才会把44取出来计算P2，而计算出来的duration时间是0.4秒。
这很奇怪，0.4秒的presentation时间让人几乎无法看清，这字幕就没有意义了。规范文档里没有提到连续多次送来TIME 02/0命令该如何解析。连续几天没有想出所以然，突然有一天在反复阅读规范文档时想到，会不会是累加。因为P2的取值范围是0x40到 0x7F，0x7F表示6.3秒，如果需要表达大于6.3秒的duration时间，岂不是需要累加表示。如果是这样，连续的9D 20命令模式中除最后一个外，前面的P2都应该是7F，这需要观察更多码流文件来验证，现在不具备这个条件。如果这样理解，我们发现的这个情况 中，duration时间应该是19.3秒。
1 /* TIME, Table 7-15 C0 control set 2 (1) Wait for process: TIME 02/0 P2 3 Processing of code as of this code is stopped for set duration by parameter 4 P2. Parameter P2 is in the range of 04/0 to 07/15 and set by binary of 6 bit 5 from b6 to b1. (b7 and b8 are not used.) Designating time should be 0.1 sec. 6 (5) Time control mode(TMD): TIME 02/8 P2 7 TIME 02/8 04/0: Free 8 TIME 02/8 04/1: Real 9 TIME 02/8 04/2: Offset 10 TIME 02/8 04/3: Unique 11 (6) Presentation start time(STM), Playback time(DTM), Offset time(OTM), 12 Performance time(PTM), Display end time(ETM): 13 TIME P P11-P1i I1 P21-P2j I2 P31-P3k I3 P41-P4m I F 14 P = 02/9 I = 02/0 I1-I3 = 03/11 15 P11-P1i = 03/0-03/9 (decimal)time 16 P21-P2j = 03/0-03/9 (decimal)minute 17 P31-P3k = 03/0-03/9 (decimal)second 18 P41-P4m = 03/0-03/9 (decimal)millisecond 19 F = 04/0 STM, DTM 20 04/1 OTM 21 04/2 PTM 22 04/3 ETM 23 At performance time, I3, P41 --- P4m is not sent out.*/
4. 多行显示字幕
字符编码数据中如果遇到0x0D，认为是要换行，多数码流里用0D命令来显示人物对话，譬如电影电视剧中AB两人的对话，一般0D前后的字幕还会用不同的颜色显示。
还有一种情况需要换行，即根据data unit中的字体大小设定、或者应用本身的设置，视频画面的宽度不够在一行里显示所有字符，需要做截断换行处理。之前的实现对字幕显示位置做了限制，只能 显示两行字幕，于是当第一行字幕（0xOD前）需要截断换行时，本该显示的第二行（0x0D）字幕就无法显示了。目前调整为放宽限制至三行。如果0x0D 前后的字符数据都有点长、需要截断换行，0x0D后的字幕将会被截断，只能部分显示。
5. 清除字幕的判断条件
字幕显示的时间可以用音视频同步的参考时钟来和视频同步，字幕数据也来自
PES包，有自己的pts（presentation time
stamp）。但是由于未知原因，我们获取到字幕数据时，其pts已经落后于参考时钟。也就是说，总是晚一步贴字幕。这个问题尚未解决。
目前的处理逻辑是，获取到字幕数据，转成图片，确定往视频帧上贴图的位置，放到队列里，渲染视频帧时如果字幕队列里有内容（read index），取出来比较其pts和参考时钟，该显示了就贴图，然后看该字幕是否有上文提到的duration信息（9D 20 XX），如果有，将其pts加上duration后和参考时钟比较，如果过期就清除。
仅仅这样还不够，如果当前字幕没有duration信息怎么办？观察码流发现，很多场景字幕不带有duration信息，我们猜测认为，这种情况下 是要依赖下一条将要显示的字幕到了该显示的时间来取代当前字幕，相当于为其清屏（每条字幕都是0C开头）。因此，不带有duration信息的字幕将一直 显示，直到其下一条字幕需要显示了。
这种场景的典型例子就是一人或多人不停地说话，后一条字幕替换前一条。如此猜测，也包含这样一个假定，如果这样集中的说话或对话结束了，接下来无人 说话或者干脆插播广告，最后一条字幕是一定会带有duration信息的。如果没有，这条字幕将一直显示着。之前我们的实现经常错误地丢弃了 duration信息，就出现这样的问题，补丁方案是对没有duration信息的字幕，赋默认值3秒。现在去掉了这个补丁，因为它会影响下一条字幕的显 示。
这又带来一个问题，如果当前字幕的duration时间比较长，譬如有10秒，而期间下一条字幕的pts已经到了该显示的时间。谁的优先级高？目前的实现是当前字幕的duration优先级高。
前面提到过，有单独的data unit，并且只有一个0x0C，而这个0x0C也有pts，这又意味着什么？目前的实现是清屏（即贴这个空字幕）时间要看0x0C的pts，而不是接受到0x0C立刻清屏。