あなろぐびでおきゃぷちゃ〜

しばらく前からアナログビデオキャプチャなんぞを行っています。最近はDVCとIEEE1394ボードを使ったデジタルビデオ編集が流行りですが、私はDVCを持っていないので（8mmなら持ってるんですが）、NTSCのビデオ信号をビデオキャプチャボードでPCに取り込んでいます。といっても、自分で映像作品を作ったりしているわけではなく、主に、テレビ番組やCFの保存用だったりしますので編集もほとんどCMカットくらいの簡単なものしかやってないです。

ここでは自分の体験などを交えながら雑談めいたことを書いてみようかと思います。

目次

1. きゃぷちゃの環境 (2001.07.01)
2. 保存形式について (2001.07.01)
3. 画面サイズについて (2001.07.09)
4. フィールドオーダーの話 (2002.01.05)
5. Uleadのソフトについて (2002.08.26)

きゃぷちゃの環境 (2002.08.07改訂)

私が普段ビデオキャプチャに使用しているマシン環境(ビデオキャプチャに関係する部分のみ)です。幸か不幸かごく一般的な環境のようです。

2002年5月にいろいろとPCパーツを買いまして環境が変化しました。以下は変更後の環境です。この変更によって、これまでSCSI HDDでしかMJPEG フルフレームキャプチャができなかったのが、IDE HDDでも楽にこなせるようになりました。やはりATA33とATA100の差は大きいということでしょうか。それとも、Ultara100カードがSCSI HAとして動作しているのがCPU負荷軽減になっているのでしょうか。

以下は私が普段使用しているビデオキャプチャ・編集関係のソフトです。

保存形式について

私は普段、キャプチャ下ファイルの最終出力フォーマットをMPEG1/2にしています。巷ではMPEG4+MP3のAVIが多いようですが、私はあえてそれを嫌っています。それは以下のような理由によります。

1. できるだけ高画質で見たい。
2. Video CDやDVD-RWに焼きたい
3. マイクロソフトは信用できない。

1については、私は320x240のサイズに満足できず、640x480や720x480のサイズで保存しているため、こういう用途にはMPEG4はやや不向きかもしれません。320x240で保存する場合は、MPEG1,2よりもMPEG4の方が、より画質を落とさずにファイルサイズを小さくできるようです。

2についてはやっぱり保存した映像をDVDプレーヤーなどで見たいからと言うのがあります。今はDVD-RWドライブなどは持っていませんが、いつか入手していざ作ろうとした場合、あらかじめMPEG1,2にしておけば再圧縮せずに済むかなと言う期待があります（2002.05にDVD-RAM/Rドライブを購入しました。結局フォーマットの違いにより昔のものは再エンコが必要になってしまいましたが）。

3については言わずもがなですが、マイクロソフトは動画に関してころころと仕様を変更しています。初めはAVIでしたがその後ASF、今は更に変わって･･･何だったか忘れた。また、使用コーデックを選ぶと言うのもあります。MPEG4にしたってV1,V2,V3の３種類のコーデックがあるのです。これらの間には互換性はありません。したがって、マイクロソフト独自仕様のAVIフォーマットおよびコーデックのサポートに不安を感じているのです。平気でコーデックのサポートを打ち切ったりしないか、もし次のバージョンのWindowsでそれらのコーデックが含まれていなければ、もう再生はできないのです。どこからかコーデックを入手しなければいけません。その点、MPEG1/2ならば国際標準規格ですから仮にWindowsがなくなったとしても再生についてはどうにかなりそうかなという気がします。

どうでしょう。人それぞれに考えはあるかと思います。私も昔、MPEG1,2の作成環境がなかった頃はMPEG4のAVIしか作れませんでした。でも、今はこれらの理由によりMPEG4 AVIを見捨てました。もちろんMPEG2で作っても再生環境はまだ十分に普及しているとはいえないでしょう。でもDVD-R/RWドライブが普及し始めようとしている今、近い将来を考えた場合、もっとも有力な選択肢だろうと言う気がします。

画面サイズについて

一般的には原ソースがNTSCの場合、キャプチャ画面のサイズについては以下のようなサイズがあります。もちろん、この他にも設定可能なサイズはいろいろとあるわけですけど、あくまでもよく使われるサイズと言うことです。

1. 320×240
2. 352×240
3. 640×480
4. 720×480

PCでのみ再生をするのであれば、1または3で良いと思います。2と4はVideo CDやDVD Videoを作成する人向けです。私自身はと言えば、最終的にMPEGで保存していることもあり、いずれはDVD-R/RWなどにDVD Videoで保存して、プレーヤーで見られるようにしたいと思っていますので、2または4で取り込みを行っています。

なお、縦サイズについてですが、480ラインで取り込む場合、NTSC信号のインターレースのことを考慮に入れる必要が出てきます。通常のテレビ映像の場合、飛び越し走査のため、240ラインの画像（フィールドと言います）2枚を1ラインおきに組み合わせた形になります（両手を組むとき、指と指の間にもう一方の手の指が入りますよね。そんな感じです）。このフィールドは1/60毎に1枚ずつ書き換えられ、フィールド2枚でちょうど1フレームを形成しているわけです。そして、この2枚のフィールドは、原則として同一時間にサンプリングしたものではなく、それぞれ1/60秒だけ時間軸のずれた映像になっています。従って、動きの激しい部分などでは2枚のフィールドの像の位置が大きく移動してしまいフレームとして見たときに像のブレが発生します。見た感じ、縞縞が走っているような感じでしょうか。これをコーミングといい、飛び越し操作を行っているビデオ信号では原理的に回避不可能なものです。

ただし、最近のCFなどでは撮影をプログレッシブで行う傾向もあるようで、こういう場合、同一時間にサンプリングした映像を2枚の絵に分けて表示しているようです。この場合は、フレームとしてみた場合でもコーミングは発生しません。逆に、映画やアニメなどではもともとは秒24コマのプログレッシブであるにもかかわらず、ビデオ信号に変換するために3:2プルダウンと言う方式で4コマを5フレーム（10フィールド）に変換しているため、どうしてもコーミングが発生する（というか異なるコマが1つのフレームに現れる）ようです。

ここからは余談になりますが、ではビデオデッキやビデオカメラなどで静止画にした場合、なぜコーミングが見えないのでしょう？それは、実はビデオデッキなどでは静止画をフレーム画像でなくてフィールド画像を縦に伸ばして表示しているからなのです。縦に伸ばす場合、2倍に伸ばさねばなりませんからラインとラインの間に一本のラインを作り出さなければいけませんが、そこはハードウェアでライン補間を行い、見た目に自然になるようにしているようです。もちろん、すべてのデッキ･カメラがフィールド表示にしているわけでなく、ビデオカメラなどでは最近では静止画をメモリカードに保存するために、むしろフレーム表示にしているものの方が多いようです。この場合、像のぶれを防止するために適応フィルタを通しているようです。これはどういうものかというと、2枚のフィールドを比較し、動きの少ないと判断した部分についてはフレーム表示で、動きの多いと判断した部分についてはフィールド補間で、というようにフィールド補間とフレーム表示を1枚の絵の中の部分部分によって組み合わせることで、ぶれのない綺麗なフレームを表示すると言うものです。最近の家電ってたいしたものですね。

フィールドオーダーの話 (2002.1.5)

「もりのみやこ」のぺえじに詳しい話が載っていますので、まずはそちらを見て頂くとして、ここではもう少し技術的な補足説明をします。

アナログ信号であるNTSCテレビ信号をデジタル信号として取り扱う場合、よくREC.601とかREC.656とかいう規格を耳にすると思います。私も規格書自体を見たわけではないのですが、REC.601というのは1982年にCCIR総会にて勧告された「スタジオ用テレビ符号化パラメータ」の規格なんだそうです。以下にその映像信号のパラメータ表を示します。

さて、REC.601では映像信号の量子化という観点での規格になっていますが、これに加えて、映像信号の伝送方法まで含めて規格化されたものがREC.656規格になるそうです（ちょっと自信がない）。この規格ではデジタルテレビ信号のいわばデータフォーマットが規格化されていると言ってよいでしょう。

デジタルテレビ信号では525/60方式において１フレーム525本の走査線を以下のように取り扱います。なお、第１フィールドは奇数フィールド、第２フィールドは偶数フィールドです。奇数フィールドとは一番先頭のラインが1ライン分あるフィールドのことで、偶数フィールドとは一番先頭のラインが半ライン分しかないフィールドのことを言います。ただし、デジタルでは半ラインという取り扱いはなく、1ライン単位で取り扱いますので、デジタルの第2フィールドは263.5Hからではなく、264Hから始まります。

つまり、映像データは第1フィールドでは242ライン、第2フィールドでは241ラインで、合計483ラインです（実際にはNTSCのデジタル映像信号は486ラインと聞きますので、さらに付加情報のライン21Hなどの計3ラインを先の483ラインに加えるようです）。

ところが、一般にはMPEGなりDVなりは525/60システムでは480ラインでエンコードしています。それでは、このNTSC486ラインのうちどの480ラインを切り出すのでしょう。実は、REC.656にはこの定義はなく、各システムの自由になっているようです。ちなみに、DVとDVDではそれぞれの規格により映像データの位置が以下のように決められています。（ちょっと自信がないが、確かこうなっていたはず）。

どちらも第1フィールドは同じですが、第2フィールドが異なっています。走査線の上下関係については、1フレームで組み合わせてみた場合、上から285H, 23H, 286Hの順に走査線が並びます。従って、DVDの場合は第1フィールドが480ラインの先頭ラインになります。これをトップファーストと一般に呼びます。しかしながら、DVでは逆に第2フィールドが480ラインの先頭ラインになってしまいます。これをボトムファーストと呼びます。

UleadのソフトなどではフィールドタイプAとかフィールドタイプBとかの呼び方になっています。フィールドタイプAがボトムファースト、フィールドタイプBがトップファーストになります（これを確認するためにDVD-Rディスクを一枚無駄にしました。このどっちがどっちっていくら探しても情報が見つからないんだもん）。

DVのようなボトムファーストの映像信号をそのままDVD用にトップファーストとしてエンコードしてしまうとどのような弊害があるでしょうか？実は、これは2種類の独立した弊害があります。

480ラインで切り出してからエンコードする場合

PCでのビデオキャプチャの場合このケースに相当します。この場合、実は時間軸が逆転してしまいます。時間軸的には必ず第1フィールドが第2フィールドよりも先です（インターレース映像の場合）。DVからキャプチャした映像は一番上のラインが2番目のラインよりも時間的に後なのです。ところが、そのままDVD用にトップファーストでエンコードしようとすると、一番上のラインを2番目のラインよりも時間軸的に先になるようにエンコードすることになります。従って時間軸の逆転が起きてしまうのです。これを防ぐにはエンコード時に一旦第2フィールドのラインを1フレーム分遅らせるなど工夫をしてやらなければいけません。

ただ、最近知ったのですが、フィールドタイプAのままでもDVD-Video形式で作成することはできるようですし、問題ないようですね。

REC.656フォーマットのままエンコードする場合

PCではこういうケースはないと思いますが、民生機では一般にこういうケースがあると思っています。この場合、時間軸の逆転は発生しません。その代わり、映像データの位置の違いによるライン欠けが発生します。例えばDV→DVDの場合、480ラインの一番上のラインが欠けて一番下に（たぶん）黒い線が入ることになります。DVD→DVの場合は逆に上に黒い線が入るのでしょう。DV→DVD→DVとした場合、上下に1ラインずつ黒い線が入ることになりそうです。

実際のDV端子付DVDレコーダーで上記のような動作になるかどうかは確かめていませんが（持ってないし）、特に何の工夫もしていなければ上記のようになるのではないかと思います。

Uleadのソフトについて (2002.8.26)

UleadのMedia StudioにしてもMovieWriterにしても、MPEG2でエンコードする際、フィールドタイプの指定をする必要があります。ところが、この指定は「フレームタイプ」「フィールドタイプA」「フィールドタイプB」の3つから選択するようになっていますが、このフィールドタイプのAとB、どっちがどっちなのか悩んだことはないでしょうか？私は悩みました。で、結局、DVD-Rを一枚無駄にして確認したところ、フィールドタイプAがボトムファースト、フィールドタイプBがトップファーストであることがわかりました。マニュアルのどこを見ても書いてないので、この程度の情報は載せておいて欲しいですね。