ISDBT中CC的处理疑问

一个针对日本的数字电视应用（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秒。

<!-- lang: cpp -->
        /* TIME, Table 7-15 C0 control set
    (1) Wait for process: TIME 02/0 P2
    Processing of code as of this code is stopped for set duration by parameter
    P2. Parameter P2 is in the range of 04/0 to 07/15 and set by binary of 6 bit
    from b6 to b1. (b7 and b8 are not used.) Designating time should be 0.1 sec.
    (5) Time control mode(TMD): TIME 02/8 P2
       TIME 02/8 04/0: Free
       TIME 02/8 04/1: Real
       TIME 02/8 04/2: Offset
       TIME 02/8 04/3: Unique
    (6) Presentation start time(STM), Playback time(DTM), Offset time(OTM),
       Performance time(PTM), Display end time(ETM):
       TIME P P11-P1i I1 P21-P2j I2 P31-P3k I3 P41-P4m I F
        P = 02/9 I = 02/0 I1-I3 = 03/11
        P11-P1i = 03/0-03/9 (decimal)time
        P21-P2j = 03/0-03/9 (decimal)minute
        P31-P3k = 03/0-03/9 (decimal)second
        P41-P4m = 03/0-03/9 (decimal)millisecond
        F = 04/0 STM, DTM
            04/1 OTM
            04/2 PTM
            04/3 ETM
       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立刻清屏。