2015-03-31
1. はじめに
2. アンテナ
3. ハードウェア
4. pt3 driver and tools
5. 予約録画・圧縮環境
6. iEPG
7. 時間
8. 想定外のtsファイル
9. まとめ
CATV（イッツコム）によるデジアナ変換地上波テレビ放送の配信が2015年3月18日正午をもって終了しました。これにともない当環境のテレビ録画・視聴システムは、IVTVとsaa713xによるアナログ地上波のキャプチャからpt3のデジタル地上波のキャプチャへと移行しました。
というわけで、一般的なハード・ソフトの対応ではとくにトラブルらしいトラブルには見舞われなかったのですが、最大の問題は受信環境でした。これまでのアナログ地上波は近隣駅ビルの難視聴対策として設置されたCATV（イッツコム）のケーブルで配信されていましたが、このケーブルにはデジタル地上波は配信されません（法制上、デジタル地上波ではその義務がないとのこと）。ただし、このケーブルには中継地点に私的（大家さん）に設置されたUHFアンテナの受信波も配信されており、実際にはデジタル地上波も受信できるようになっています。しかしながら、送信出力の弱いMXTVだけは十分な受信強度を得ることができない現状です。
この受信環境の問題は当環境固有の問題なのであまり深く踏み込みませんが、当環境のデジタル地上波対応に関する費用・労力の八割はこの受信環境の問題に注がれました。この問題は次項の「アンテナ」でほぼ解決しますが、多くの人の興味はpt3への対応やtsファイルの問題にあろうことを考えると、この記事全体の着眼点や方向性に筆者と多少の温度差を感じるかもしれません。
次項、「アンテナ」以下、pt3のハードウェア環境を整え、予約録画機能を実装します。予約録画に関してはEPGの問題についても考え、また、録画開始時のタイムラグに対応するためシステムの時計を二秒弱ほど進めてみます。最後に不完全なtsファイルの対処法について検討します。なお、pt3は衛星放送にも対応しているので実家のBSアンテナに寄生する録画環境もあわせて構築しています。
前述した当該のUHFアンテナはスカイツリーを向いていますが、アンテナの目の前には建物が存在しており、環境としては最悪、MXTVがC/N比15dB程度で正常に受信できません。ここで周囲のアンテナ状況を観察してみると半分以上はスカイツリーとはあさっての方向を向いており、それらのアンテナは近くの山の反射波を拾っていると思われます。
反射波でもそれなりの強度が得られるようであること、その他いろいろあって、結局、MXTVの受信には自前でアンテナを設けることにしました。とりあえず、軒先の物干し竿に八木アンテナ（マスプロ電工 U146 14素子2,170円）を括りつけ、近くのビルの反射波を拾っています。30度強の角度をつけて物干し竿に括りつけられた八木アンテナは見た目ちょっと変ですが、懸案のMXTVもC/N比23dB程度で受信でき、なんとか問題のないレベルとなりました。ケーブルの取り回しは、アルミサッシ上辺のレールの隙間にその部分だけ細い同軸ケーブルに変換して通しています。いわゆる隙間ケーブルみたいな物は使っていません。隙間ケーブルは、結局、サッシを無理やり閉める形になるのでどうも落ち着きません。
アンテナが準備できたら受信できるチャンネルを確認してみます。BSなどはチャンネルが決まっているのでとくに問題になることはないのですが、地上波は地域ごとに異なるのでそれぞれ調べる必要があります。以下のコマンドは地上波デジタルを全探査（13ch~63ch）します。デジタル地上波は、C/N比19dBが境界線で、19dBをきるとブロックノイズが出始め、17dB台では映像データの復号自体が失敗するようになります。
$ checksignal.sh
13:0dB:
14:0dB:
15:0dB:
16:23.719490dB :ＴＯＫＹＯ ＭＸ１/ＴＯＫＹＯ ＭＸ２
17:0dB:
18:18.459760dB :
19:0dB:
20:0dB:
21:32.165039dB :フジテレビ/フジテレビ/フジテレビ
22:28.824814dB :ＴＢＳ１/ＴＢＳ２
23:29.088403dB :テレビ東京１/テレビ東京２/テレビ東京３
24:28.261051dB :テレビ朝日/テレビ朝日/テレビ朝日
25:30.359753dB :日テレ１/日テレ２
26:26.080074dB :ＮＨＫＥテレ１東京/ＮＨＫＥテレ２東京/ＮＨＫＥテレ３東京
27:29.842148dB :ＮＨＫ総合１・東京/ＮＨＫ総合２・東京
28:29.922065dB :放送大学１/放送大学２/放送大学３
29:0dB:
30:2.126431dB :
31:0dB:
32:0dB:
以下略
左から物理チャンネル、C/N比、放送局名になります。上記は東京の例です。18chはTVKで、映ったり、映らなかったり、非常に不安定でどう対処するのが正しいのか苦慮しています。ひとまず、映らないものとして扱っています。
さて、山形の実家にはBSアンテナが設置されてあるのでこれを利用するビデオサーバも構築してみました。するべきことは母屋に設置されたBSアンテナのケーブルをビデオサーバのある旧母屋まで引き回すだけとはいえ、最短距離を考慮すると意外に厄介なのですが、ちょうどいいところにケーブルの継ぎ目があり、そこから簡単に分岐できたのは幸運でした。BSアンテナのケーブルの取り回しは実家の古い建物なので遠慮なく壁に穴を開けています。C/N比は雨風雪に関係なく15dB強（BSでは問題ないレベル）で安定しています。衛星放送の受信は天候に左右されるようなことを良く聞いた気がしますが、今のところまったくそんな感じはしません。
当初、深夜のBS放送の録画失敗が頻出し、少し悩んだのですが、原因は、深夜には実家のテレビが動作していないためパラボラアンテナへ給電されていない、というものでした。これは、pt3が自力給電（-lnbオプション）することで単純に解決します。
また、地上波に関しては母屋からケーブルを引き回す手間をとるより簡易な室内アンテナを自前で用意しています。前述したように14素子の八木アンテナも2,000円程度で買えるのですが、八木アンテナを室内で使用するのはサイズと重量の問題があるし、市販の簡易アンテナ・室内アンテナは形状や性能に難がある上、割高感があるので自作することにしました。クリーニングのワイヤーハンガーを加工して円周60cm(500MHz 1λ)のループアンテナを二つ作り、それをスタックしています。実際にはシングルでも十分な利得があったのですが、インピーダンスと物理的安定性（中心に給電点がくる）の側面から８の字のダブルスタックにしてみました。
ループアンテナの長所は波の向きに対応しやすいことや比較的利得が大きいことなどがありますが、素人的には工作のしやすさが一番だと思っています。素子が二つのダイポール系のアンテナでは二つの素子を一つに固定する方法が必要ですが、素子が一本しかないループアンテナではその面倒がないからです。さらに直線と円では単純に強度が違います。このアンテナでは二つのループアンテナの両端をそれぞれハンダ付け、その二つの接続部から二線をコネクタにほぼ空中配線し、あとはその部分をいわゆるホットボンドで一気に固めています。性能的には全局でC/N比30dBを越えており、Dpaの受信エリアマップ的にはけっこう外縁にありながらも余裕の運用です。もっとも、受信環境はアンテナの性能より周囲の物理環境の影響の方が大きいのでアンテナ云々は特筆するほどのこともなく、遮るものが何もないという数少ない田舎の利点が活きた、と言えましょう。また、こんな単純なアンテナでも細かい調整もなしに安定した受信が可能なのはやはりデジタルの優秀性だと実感します。
最後にループアンテナの非常に現実的な欠点・危険について注意喚起しておきます。最近のAV機器にはブースターやパラボラアンテナへの給電機能がありますが、ループアンテナに給電してしまうと当然ショートします。pt3の運用中、BS/CSではパラボラアンテナへ給電（-lnbオプション）していることも多いかと思われます。この設定を変更せずに地上波でも給電してしまうとループアンテナではショートします。保護回路はついているような気もしますが、希望的観測にすぎません。
自宅のビデオサーバは新環境のために新調しました。秋葉原のDOSパラでどこかのショップブランド品と思われる中古機を7,980円で購入、今時はCore2Duoの機体がこの値段で買えるとは良い世の中です。これに1TBのHDDとキャプチャ関連のハードを増設しています。
ハード構成としては特に変わったところはないのですが、デジアナ変換チューナ使用時の検証用アナログキャプチャカード(WinTV PVR150)とPT3用のカードリーダー(Panasonic 7A-smart)が一般的ではないと言えるでしょうか。B-CASカードはデジアナ変換チューナ（詳細不明中古品、2,200円くらい）についてきたものを使用しています。なぜか二枚ついてきたのでデジアナ変換チューナもPT3も同時に動かせます。
| Main board |
ASUSTeK P5Q-EM |
| CPU | Intel Core2Duo E8400 3.0GHz |
| chip set | Intel G45 |
| RAM | DDR2 SDRAM 1GBx4 |
| on board video | GMA X4500HD |
| on board sound | Realtek ALC 1200 |
| on board ethernet |
RealTek 8111C PCI-E Gigabit |
| TV capture card | Earthsoft PT3 |
| USB Card Reader |
Panasonic 7A-Smart |
| TV capture card | Hauppauge WinTV PVR 150 |
| HDD | WDC WD2500JD-19H 250GB |
| HDD |
WDC WD10EADS-00L5B1 1TB |
| DVD-RAM | HL-DT-ST DVDRAM GH20NS10 |
実家のBS用ビデオサーバは寄せ集め自作機です。2,000円くらいのマザーボードと1,000円くらいの箱を買って、あとは手持ちの物で隙間を埋めました。この機体のB-CASカードもこの機体用に購入したデジアナ変換チューナの物なのですが、自宅用の機体とは違い、直接さわって検証できるわけではないのでアナログ環境は実装していません。
ちなみにPentium4 651 3.4GHzとCore2Duo E8400 3.0GHｚのパワーの違いは歴然で、pt3でキャプチャした30分のtsファイルをh264で解像度1024x576のファイルへ変換するのに前者は約四時間、後者は約一時間しかかかりません。四倍というあまりの差に何か間違ってるのか？と疑うレベルなのですが、とりあえず、間違いは見当たりません。これで私のクロック信仰は完全に終了しました。
| Main board |
Aopen i915Gm-PL |
| CPU | Intel Pentium4 651 3.4GHz |
| chip set |
Intel 915G + ICH6 |
| RAM | DDR2 1024MB + 512MB |
| on board video |
Intel i915G |
| on board sound | Azalia Codec on-Board |
| on board ethernet card |
Marvell 88E8053 |
| TV caputure card |
Earthsoft PT3 |
| USB Card Reader |
Panasonic 7A-Smart |
| SATA HDD | Hitachi HDS72161 P22O 160GB |
| SATA HDD | Seagate ST31000526SV 1TB |
| DVD-RAM |
MATSHITA DVD-RAM SW-9587S |
OSはVine Linux 6.2をフルインストールしています。Vineを選択している理由はとくにはありません。インストール、アップデートの後、mplayerやffmpegなどのマルチメディア関連ソフトもインストールします。
pt3に関して必要なものは、まずはドライバで、次に受信のためのツール(recpt1)、そして、B-CAS対応（暗号解除）のためのツール(arib25)になります。B-CAS対応に関してはカードリーダドライバやソフトが必要ですが、後述します。まずは、ドライバをインストールします。
$ wget https://github.com/m-tsudo/pt3/archive/master.zip
$ unzip master.zip
$ cd pt3-master
$ make
$ su
# make install
# bash ./dkms.install
とくに問題なくインストールできると思います。./dkms.installは、kernelを更新した場合、自動でpt3のドライバもリビルドしてくれるようになる機能拡張です。
次にrecpt1ですが、recpt1はarib25に依存しているので先にarib25をインストールします。arib25のリビルドには、pcsc-lite-develが必要です。その他は、とくに言及することもないので詳細はSRPMの中身を参照してください。
arib25-0.2.5-0pe3.src.rpm
$ rpm -i arib25-0.2.5-0pe3.src.rpm
$ rpmbuild -bb rpm/SPEC/arib25.spec
$ su
# rpm -Uvh rpm/RPMS/i686/arib25-0.2.5-0pe3.i686.rpm
そして、recpt1ですが、recpt1にはいろいろな亜種がありますが、このrecpt1は基本的にシンプルなものになっています。詳細はSRPMの中身を参照してください。
recpt1-20130323-0pe1.src.rpm
$ rpm -i recpt1-20130323-0pe1.src.rpm
$ rpmbuild -bb rpm/SPEC/recpt1.spec
$ su
# rpm -Uvh rpm/RPMS/i686/recpt1-20130323-0pe1.src.rpm
最後にB-CAS用のカードリーダドライバとソフトについて言及します。カードリーダドライバはpcsc-lite、pcsc-lite-libsとccidで、pcsc-lite関連はarib25をリビルドした際にすでにインストールされているはずです。カードリーダの使用にはpcsc-liteに含まれるpcscdという制御デーモンを起動させておく必要があります。デフォルトでもブート時に起動するようになっていますが、挙動がおかしい時は確認してみてください。
ソフトはpcsc-toolsで、実際にユーザが直接使ってみるのは、その中のpcsc_scanです。pcsc_scanにより、現在、認識されているカードリーダ、カードを参照します。pt3用のカードリーダと言えばNTT ComのSCR3310がデファクトスタンダードになっているようですが、ここではカードリーダは、Panasonic 7A-Smart（本体表示型番 ZU-9PS）を使用しています。しかし、Vine Linux 6.x(ccid-1.3.8-2vl6)のデフォルトではPanasonic 7A-Smartは認識しないので設定ファイルに追加設定する必要があります。
大雑把に言って、USBカードリーダはみな同じです。ドライバに認識されないのはそのUSBカードリーダがカードリーダとして登録されていないからで、ベンダーIDとプロダクトIDと認識名を下記ファイルに追加登録すればそのUSBカードリーダがカードリーダとしてドライバに認識されるようになります。
/usr/lib/pcsc/drivers/ifd-ccid.bundle/Contents/Info.plist
Panasonic 7A-Smart（本体表示型番 ZU-9PS)対応Info.plist
とりあえず、下記のようにdmesgなどで調べて
usb 8-2: new full-speed USB device number 3 using uhci_hcd
usb 8-2: New USB device found, idVendor=04da, idProduct=117a
usb 8-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 8-2: Product: Panasonic USB Smart Card Reader 7A-Smart
usb 8-2: Manufacturer: Panasonic
その情報をInfo.plistに追加します。
<key>ifdVendorID</key>
<array>
<string>0x08E6</string>
〜 略 〜
<string>0x04DA</string>
</array>
<key>ifdProductID</key>
<array>
<string>0x2202</string>
〜 略 〜
<string>0x117A</string>
</array>
<key>ifdFriendlyName</key>
<array>
<string>Gemplus Gem e-Seal Pro</string>
〜 略 〜
<string>Panasonic USB Smart Card Reader 7A-Smart</string>
</array>
書き換えたら、pcscdを再起動し、pcsc_scanで現状を確認してみます。
# /etc/init.d/pcscd restart
# pcsc_scan
PC/SC device scanner
V 1.4.17 (c) 2001-2009, Ludovic Rousseau <ludovic.rousseau@free.fr>
Compiled with PC/SC lite version: 1.5.5
Scanning present readers...
0: Panasonic USB Smart Card Reader 7A-Smart 00 00
〜 中略 〜
Possibly identified card (using /usr/share/pcsc/smartcard_list.txt):
3B F0 12 00 FF 91 81 B1 7C 45 1F 03 99
Japanese Chijou Digital B-CAS Card (pay TV)
上記のように表示されれば完了です。なお、pcsc_scanを終了するにはCtrl+Cで終了させてください。
この7A-Smartは秋葉原の某ジャンク屋で350円くらいで大量に売っていたものです。ネット上での情報量とリスクを勘案すれば2,000円くらいまでならSCR3310を選択しましたが、SCR3310は、現状、高価過ぎます。
録画予約には、atを利用した独自のシェルスクリプトcgiで対応しています。当環境には常時稼動のメインサーバが存在するので、メインサーバが録画予約情報を録画サーバと共有し、録画予約の時間が近づくとメインサーバが録画サーバをWOLで起動させるようになっています。録画終了後は、tsファイルを圧縮し、それらの事後処理が終了すれば録画サーバは自らシャットダウンします。
なお、実際にこの記事を参考に再現・運用してみようとする人はいないと思うので詳細は割愛し、以下、運用中の現物の公開だけにとどめます。
menat-web2.cgi
web上から録画予約情報を作成または削除するcgi。
menat-sad2.sh
上記cgiで作成された録画予約情報をatに登録するデーモンのようなもの。録画サーバ上でcronにより10分毎に実行されている。また、予定の処理が終了すれば自らシャットダウンする。
menat-vs2.cgi
作成された動画ファイルをweb上から参照・管理するcgi。
menat-cap.sh
事実上、recpt1のただのラッパー。
menat-cmp2.sh
recpt1が生成したtsファイルを圧縮するシェルスクリプト。現在、適正な設定を模索中。最近の主流は、H.264、1024x576、1600kbps、400MB、または、H.264、800x450、800kbps、200MB。
これで生成したH.264の動画をmplayerで再生すると横スジのノイズが出る（横スジの上下で描画の遅延が生じている？）時があるのですが、Windows 7のメデイアプレーヤーではまったく問題がないのでLinux版mplayerの特有の問題に思われます。
menat-bp.sh
バックアップを兼ねて、ケイタイ(docomo P904i)用の動画ファイルを生成する。参考のためにffmpegのオプションを紹介しておく。
$ ffmpeg -y -i original.ts \
-s 320x180 -aspect 4:3 -vcodec libx264 -fpre libx264-p904i.ffpreset \
-padtop 30 -padbottom 30 -b 200k -r 14.985 \
-acodec libfaac -ar 32000 -ab 32k -f 3gp output.3gp
P904iは、H.264の場合、4:3のアスペクト比以外では映像に乱れる部分が出るので映像の上下にそれぞれ30pxのパッドを詰めて解像度を320x240に調整している。
menat-getiepg.sh
iEPGによる番組情報を取得する。
menat-midentify
各種動画ファイルの仕様・情報を表示する。
menat-mkprog2.sh
iEPG情報を元に独自の番組表を作成する(6. iEPG)。
menat-tk2.sh
録画サーバの時間を、適宜、進める(7. 時間)。
checkts.sh
tsファイルを検証し、ffmpegに適切なオプションを提示する(8. 想定外のtsファイル)。
menat-wol2.sh
録画予約情報を参照し、録画サーバをWOLで起動させる。
システムとしての録画予約機能は前項で完成しました。しかし、快適な予約録画を実現するためには番組表は必須です。現在のデジタル波TV放送では番組情報をEPGデータとして同時配信しており、これを利用できれば自己完結的なシステムが構築可能なのですが、この番組情報（EPGデータ）の運用はあまりに酷く、正直、実用に堪えません。
まず第一に番組を一意に特定するIDが存在しないというのがダメすぎです。ちなみに仕様上は存在していて、シリーズナンバーなども管理できるようになっているのですが、実際の運用では採用されておらず、さらに番組特定のキーであるはずの番組名も話数やサブタイトルの付記で一意性が汚染されており、さらにそれらの対応は各局・各番組毎に異なっているという状況でどうにもなりません。EPGデータの利用など、まったく考慮されていない、どころか、わざと使えないようにしているとしか思えないレベルです。
この惨状を憂い、有志で独自の番組表を作成しているところもあるようですが、ここではiEPG（web上に存在する番組表掲載サイト・TV王国）を利用することにしました。ただし、iEPGもEPGとまったく変わらないと言っていいほど問題点は同じです。それにもかかわらずiEPGを選択する理由は、ネット経由のダウンロードによるデータ取得のため負荷が小さいことと受信環境の状態に影響を受けない（データの取りこぼしがない）ことです。EPGは現状のiEPGに比較して即応性に優れ、番組や時間の変更にも対応しやすいのですが、結局、この利点も運用次第のものであって現段階においては信頼に足るものではありません。
というわけで、一日に一度、テレビ王国の番組表から必要な情報だけを抜き出して簡素な番組表を再構成し、その番組表から簡便に予約録画できるようにしています(menat-mkprog2.sh)。
正確な時間で録画を開始すると事前処理・その他の関係で実際の録画開始に若干（一秒弱程度）の遅れが発生し、遅延の分だけ冒頭部分の録画漏れが生じます。これを回避するため、録画サーバの時計をわずかに早めます。ntpdに遅延や早進を制御するようなオプションはないようなので、このためにntpサーバと同期しつつ任意の時間差を維持するシェルスクリプトを書きました(menat-tk2.sh)。このスクリプトはntpdの代替として11分毎にntpサーバに時刻を問い合わせ、適切な時間になるようにシステム時計の進行速度を微調整します。進行速度の調整のためにadjtimexが必要です。
自宅の録画サーバでは、1.6秒、実家の録画サーバでは、2.0秒、進めています。これで番組の冒頭部分が欠けることがなくなりました。二つのサーバの0.4秒の差は単に検証のためのものですが、今のところ、認識できるほどの差は感じられません。また、このスクリプトにより生じる誤差は、概ね0.1ms以下におさまっており、十分な精度だと思います。
実際の運用では、下記をrc.localで起動時に実行しています。
/root/bin/menat-tk2.sh time_server proceed_seconds &
電波の受信は様々な理由から必ずしも送信者の想定通りにはいきません。なので、ときに想定外のtsファイルが生成されることになります。ここでは想定外のtsファイルへの対応について考えてみます。具体的に言えば、recpt1が生成したtsファイルをffmpegがエラーを出して正常に圧縮できない場合の対応法です。まず、どのようなパターンがあるか列挙します。各エラー名はここだけでの仮称です。
・tsエラー
受信強度などに問題があり、正常なtsファイルが生成されなかったエラー。mplayer、ffmpegなどで調べても必要なtsファイルのパラメータが取得できない完全に壊れたtsファイルには対処の方法はありません。
・decrypteエラー
PT3は複数のチューナを持っており、二つ以上のチューナを同時に起動させた時、ごくまれにカードリーダの取り合いになってB-CASデータの取得に失敗するときがあります。この場合、B-CASデータの取得に失敗したチューナでは復号されていないtsファイルができあがり、当然、そのtsファイルは正常に再生できません。このtsファイルは、b25(arib25)で復号することができます。
$ b25 encrypted.ts decrypted.ts
・プログラムエラー
ffmpegがprogram IDを認識できず、対応する番組を読み出せないことがあります。ただし、これまでの経験（1,000回弱くらい）ではデフォルトの番組でこのエラーが起きたことはありません。MX2などの第二番組やワンセグではまれに生じるようですが、ほとんどの場合、mplayer(mencoder)では読み出せるようです。
・デフォルトエラー
ffmpegではprogram IDのもっとも若い番組をデフォルトの番組と認識しており、また、mplayerでは別の方法でデフォルトを決めています。つまり、両者でデフォルトの番組に違いが生じる時があります。事実上は、ffmpegの認識で正しいのですが、この場合、ffmpegの挙動がどうなるかというと、映像は正しいが音声はmplayerのデフォルトの番組のものが使われてしまうという結果になります。この齟齬を回避するには、ffmpegに対し、明確にデフォルトのProgram IDを指定してやる必要があります。
・ストリームエラー
データ（音声または映像）ストリームには適切な開始位置が存在しますが、任意の時間から電波を受信するという環境では必ずしも適切な位置からファイルが生成されるとは限りません。不適切な位置からストリームが開始しているとffmpegはそのストリームを読み込めず、そのまま終了することがあります。そこで、この場合、開始位置をずらしてやります。具体的には-ssオプションで開始位置を0.01秒ほど先に進めます。なお、-ssオプションは指定する位置により挙動が異なるので、この場合は入力ファイルよりも前（コマンド側）で指定してください。
さて、tsファイルの圧縮の自動化の観点から上記のエラーを判別し、対応策をとれるようにします。checkts.shは指定したファイルのデフォルトのprogram IDと必要であれば開始位置の時差を出力します。時差の決定は成功するまで最大10回（0.1秒）まで試行します。とはいえ、これまで3回以上試行したことはありません。返り値は、1がデフォルトの番組の読み込みエラー、2がデフォルト以外の番組の読み込みエラー、4が音声のストリームエラー、8が映像のストリームエラー、すべてのストリームで再生不可の場合が16、32がデフォルトエラー、65がdecrypteエラー、67がtsエラーで、最終的な返り値はこれらの総和になります。なお、このスクリプトは、一時的な受信障害等で部分的に欠損が生じたようなエラーは検知できません。
$ checkts.sh test.ts
-programid 23608:0:1:MPEG2(pid=273) AAC(pid=274):0:0:1:8:8
-programid 23609:0:0:MPEG2(pid=305) AAC(pid=306):0:0:0:0:8
-programid 23992:0:0:H264(pid=641) AAC(pid=643):0:0:0:0:8
-programid 23993:1:0:H264(pid=897) AAC(pid=899):0:3:-1:-1:10
-programid 23608 -ss 0.01
青文字は標準エラー出力で最終行だけが標準出力です。標準エラー出力では簡易に情報を出力しており、標準出力にはffmpegの実行に必要なオプションだけが出力されています。この例では、デフォルトの番組で映像のストリームエラーと第二番組(TOKYO MX ２)のワンセグでプログラムエラーが検出されています。返り値は10(2+8)です。
やっとテレビ環境のデジタル化も終了しました。感想としては、やっぱりデジタルはキレイですね。なんと言うか、文明の勝利、とでも言いたくなります。H.264による圧縮も高品質で、もっと前に移行すれば良かったかな、と思わないでもないのですが、いろいろと枯れるまで待ったのも、まぁ、間違いではなかったとも思います。
しかし、MXが映らないのには虚を突かれました。何故にそんな状態が今まで放置されてきたのか、正直、わからないのですが、肝腎の大家さんがまったく理解していないのでお手上げです。あのアンテナの方向をご近所のアンテナと同じ方向に調整すればたぶん大丈夫だと思うのですが、それにもお金がかかるわけですし…、電気屋にとっては、ひと粒で二度美味しい…。
とにもかくにも、デジタルへの移行は電気屋には特需だったのだとつくづく思いました。実家のUHFアンテナも電気屋に言われるがまま、新設の必要もないのに新設し、さらに近距離用のアンテナも新設させられているという、それなんて詐欺？状態です。おまけにその近距離用アンテナのケーブルは長すぎて途中でコイル状にぐるぐる巻にされており、ホントに電気屋なのか？と疑うばかりです。そういえば、子供の頃、ゲルマニウムラジオの部品を集めるべく、街の電気屋へ行き、その対応のトンチンカンさに失望したことを思い出しました。私が理系に進まなかった原因の20%は街の電気屋のせいです。
まぁ、そんな愚痴は置いておいて、一般的な解法とは異なる録画サーバの構築例はいかがだったでしょうか？できるだけ部分的な再利用が可能なように意識したつもりですが、それ以前に、一人よがりに十年以上も更新を重ねてきたシステムは他人にはもはや意味不明なのでは…、といささか不安でもあります。毎度のことながら、何かのネタになれば喜ばしいかぎりで、ご意見、ご質問等、気軽にしていただければ幸いです。
2015-03-31 よしのぶ