UCS(UTF-8)とラテン文字の字幕に対応

[xtne6f]

南米圏(SBTVD)およびフィリピン(UCS符号化方式)の字幕への対応を意図したコミットです。
直接の規格書はおそらく有料なので具体的に示すことはできないのですが、例えば
tsduck/tsduck#667
にて関連文書へのリンクが紹介されています。

UCS符号化方式についてはSTD-B24で規格されている(TCS(文字符号化方式)が1の場合)ので、このうちUTF-8の規定に沿って実装しています。※UTF-16についての規定もあります(おそらく採用例なし)が必ずByteOrderMarkがつくとされています。

(違法でない範囲での)サンプルデータは南米だと例えば
https://streams.videolan.org の streams/ts/ARIB/ にあります。TVTestで試験する場合、パネルの字幕表示は現状小さい文字が振り仮名扱いになるため設定の調整が必要です。フィリピンについては残念ながら未発見です。

実のところTVTestをSBTVD等に対応させる必要があるかと問われると心苦しいのですが、個人的にUCS符号化方式の規定を活用したツールを作っていることもあり、対応してもらえるととても助かります。

[DBCTRADO]

ご提示のサンプルを再生して字幕パネルを見てみましたが、同じ文が繰り返し現れるのはなぜでしょう。

[xtne6f]

繰り返しになるのはロールアップモードによる挙動と思います。
日本ではたぶん実用されていない(しかしTR-B14にもオプションとして存在する)ですが、2行や3行程度を逐次送っていく方式のようで、ロールアップモードを意識せずに文字列として書き出すと行数に応じた回数だけ繰り返し現れることになると思います。
字幕プラグインなどで表示させてみると(TR-B14とは異なりCSが送られないので画面消去が変ですが)おおむね問題ない表示になります。

[xtne6f]

すみません、字幕のPESデータを解析したところロールアップモードではなさそうです。(ロールアップモードならば同じ行を2回は送らないと思われます)
意図して同じ内容の行を2回（2回目は縦の位置を一行分上に移動させて）送出しているので、文字列として書き出すと繰り返し現れてしまう点については一応やむを得ない挙動と思います。

[DBCTRADO]

詳しくありがとうございます。
字幕パネルのように文字列として蓄積させていくのは字幕の本来の表示方法ではないので、変になる部分が出るのはやむを得ないところではあります。

一点気になるといえば、言語による決め打ちでラテンの判定をしていることです。
運用上は日本の放送で日本語以外の字幕が送信されることは無いと思いますが、規格上はスペイン語等の字幕もあり得るはず。
ブラジルの放送でポルトガル語以外の字幕があり得るのかは知りませんが、同様の懸念がある。
他に良い判別法がなければ仕方ないかな、というレベルではありますが。

[xtne6f]

実運用では"jpn"と、一部のCS局で第2字幕に"eng"が使われているようです。
STD-B24の8単位符号の文字集合でスペイン語を満足に表現できるのか？というのもありますし、日本の放送で"spa"や"por"はまず来ないでしょうが逆にSBTVDで"eng"が来る可能性は、想像するしかないですがあり得るかもしれませんね…。STD-B24では8単位符号の初期状態がGLテーブルに漢字系集合、GRテーブルにひらがな集合なので文字化けすると思います。
G1テーブルが英数集合でSBTVDと共通なので、"eng"を使う場合に最初に「G1をGLかGRに呼び出す」のであれば相互運用できそうですが、そこまで互換を気にしていないかもしれません。

TVCaptionMod2字幕プラグインをSBTVD対応するにあたって参考にしたのがaribb24ライブラリの
nkoriyama/aribb24#16
の議論で、おそらくSBTVD圏の方からのプルリクエストです。識別方法はやはり字幕管理データのISO_639_language_codeで、自分もこれ以外の方法をちょっと思いつかないです。libaribcaptionの識別方法もやはり同様です(この方もおそらく上記のプルリクエストを参考にしたと思う)。
xqq/libaribcaption@c4e58ae

[DBCTRADO]

日本の放送を扱う場合において問題が起こる可能性はほぼ無いと思われるので、このままマージします。
今後、言語による判別の動作を変更できるようなオプションを CaptionParser に追加するかも知れません。

[xtne6f]

ありがとうございました。振り仮名についてTVTestの対応として
xtne6f/TVTest@00b38a2
も参考にしてもらえると嬉しいです。

本件とは直接関係なく補足です。videolan.orgの件のサンプルで字幕プラグイン(TVCaptionMod2やTVCaption3)の画面消去が上手くいかないと書きましたが、TR-B14の規定を正しく表現できていないためでした。
件のサンプルの字幕は空白(SP)を補って常に幅を揃えることで前の字幕を上書きしながら送っていくため画面消去(CS)はそもそも不要で、この「後ろの字幕による上書き」を正しく表現できていない字幕プラグイン側の落ち度です。(TVCaptionMod2の現行masterにて修正を行いました)

[DBCTRADO]

そちらの変更も取り入れたいと思います。

妙に空白が含まれていると思ったら、そんな手法があるんですね。