JP2002135707A - 映像編集システム - Google Patents

Abstract

(57)【要約】 【課題】 編集作業を行うことを決定してから、実際に
編集作業を開始するまでにかかる時間を短縮することが
できる映像編集システムを実現する。 【解決手段】 サーバ２０は、ビデオデッキ１１により
再生されたビデオテープ１２の映像のサムネイル画像、
クリップ開始点・終了点などの編集情報を生成し、編集
情報記憶部３２に記憶する。クライアント４０は、希望
する編集情報をサーバ２０から受信し、その編集情報に
基づいて編集作業を行う。クライアント４０は、編集作
業が終了すると、編集指示をサーバ２０に行い、サーバ
２０は、編集指示に従って映像・音声ストリーム記憶部
３１から映像・音声ストリームを読出して編集を行い、
ＤＶＤライタ１３によりＤＶＤ−Ｒに記録する。サーバ
２０からクライアント４０へ送信される編集情報は、元
の映像よりもデータ量が小さいため、通信時間が短く、
編集決定から開始までの時間を短縮できる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この発明は、サーバおよびク
ライアント間で映像の編集を行う映像編集システムに関
する。

【０００２】

【従来の技術】図１６ないし図１８は、従来から行われ
ている動画の編集手法の一例を示す説明図である。従来
は、１つの動画をいくつかのクリップ（Ｃｌｉｐ：場
面）に分け（図１６）、それらのクリップの再生順序を
変更したり（図１７）、作成したクリップの不要な部分
を削除して新たなクリップを作成したりするなどの手法
が用いられている（図１８）。また、それらの手法を用
いる場合、クリップの長さをＧＵＩ(Graphical User In
terface)上に表して編集する手法が知られている。

【０００３】

【発明が解決しようとする課題】しかし、上記従来の手
法では、編集の程度により必要な情報量が異なるにもか
かわらず、総ての動画情報を用意しなければならない。
たとえば、あるクリップと別のクリップとを入れ替える
だけの簡単な編集作業を行う場合は、それぞれのクリッ
プの先頭部分の画像が分かれば編集作業を行うことが可
能であるが、あるクリップ内の不要部分を削除したい場
合には、該当するクリップ中の総てのコマの画像がなけ
れば編集作業が困難である。また、上記編集作業をネッ
トワークを介して接続されたサーバおよびクライアント
間で行う場合は、クライアントは、編集作業に先だって
総ての動画情報をサーバから受信する必要があるため、
サーバからクライアントへのファイルの転送に長時間を
要する。このため、クライアント側は、簡単な編集作業
を行いたい場合であっても、ファイルの転送が完了する
まで（編集に必要のない情報も含めて総て取得するま
で）編集作業を開始することができない。また、クライ
アント側は、クリップの後尾部分を参照したい場合にお
いて必要なのはクリップの後尾部分であるが、先頭から
後尾までの総てのファイルの転送が終了するまで編集作
業を開始することができない。特に、電話回線経由で編
集作業を行う場合は、企業内のＬＡＮなどと比較してネ
ットワークの帯域が狭いため、ファイルの転送に長時間
を要するので、編集作業時間はより一層増加するし、通
信コストも増大してしまう。

【０００４】そこで、この発明は、上記諸問題を解決す
るためになされたものであり、編集作業を行うことを決
定してから、実際に編集作業を開始するまでにかかる時
間を短縮することができる映像編集システムを実現する
ことを目的とする。

【０００５】

【課題を解決するための手段、作用および発明の効果】
この発明は、上記目的を達成するため、請求項１に記載
の発明では、サーバと、このサーバと通信可能なクライ
アントとを備えており、前記サーバは、映像を編集する
ための編集情報を記憶する編集情報記憶手段と、前記ク
ライアントから送信された送信要求信号を受信する送信
要求信号受信手段と、この送信要求信号受信手段により
前記送信要求信号が受信された場合に、前記編集情報記
憶手段に記憶されている編集情報のうち、前記受信され
た送信要求信号により示される内容に対応した編集情報
を部分編集情報として前記クライアントへ送信する編集
情報送信手段とを備えており、前記クライアントは、前
記編集情報記憶手段に記憶されている前記編集情報のう
ち、どの部分を部分編集情報として受信するかの要求を
示す送信要求信号を前記サーバへ送信する送信要求信号
送信手段と、前記サーバから送信されて来た前記部分編
集情報を受信する編集情報受信手段と、この編集情報受
信手段により受信した部分編集情報に基づいて所望の編
集映像に対応する編集情報を編集する編集手段とを備え
たという技術的手段を用いる。

【０００６】サーバに備えられた編集情報記憶手段は、
映像を編集するための編集情報を記憶しており、クライ
アントが、上記編集情報のうち、どの部分を部分編集情
報として受信するかの要求を示す送信要求信号をサーバ
へ送信すると、サーバは、受信した送信要求信号により
示される内容に対応した編集情報を部分編集情報として
クライアントへ送信する。そして、サーバは、受信した
部分編集情報に基づいて所望の編集映像に対応する編集
情報を編集する。つまり、クライアントは、映像を編集
するために必要な編集情報をサーバから受信し、その編
集情報により編集を行うことができるため、総ての映像
を受信する必要がない。したがって、従来のように、ク
ライアントが総ての映像を受信してから編集作業を行う
手法よりも、編集作業を行うことを決定してから実際に
編集作業を開始するまでにかかる時間を短縮することが
できる。また、サーバ・クライアント間の通信時間を短
縮できるため、通信コストを低減することもできる。ま
た、サーバは、クライアントから送信された送信要求信
号により示される内容に対応した編集情報をクライアン
トへ送信することができる。したがって、クライアント
は、サーバから受信した編集情報が希望するものでない
場合は、送信要求信号を変更することにより、希望する
編集情報を受信することができる。

【０００７】請求項２に記載の発明では、サーバと、こ
のサーバと通信可能なクライアントとを備えており、前
記サーバは、映像を編集するための編集情報を記憶する
編集情報記憶手段と、この編集情報記憶手段に記憶され
ている編集情報のうち、どの部分を部分編集情報として
前記クライアントへ送信するかを設定した設定手段と、
前記クライアントから送信された送信要求信号を受信す
る送信要求信号受信手段と、この送信要求信号受信手段
により前記送信要求信号が受信された場合に、前記編集
情報記憶手段に記憶されている編集情報のうち、前記設
定手段により設定された内容に対応した編集情報を部分
編集情報として前記クライアントへ送信する編集情報送
信手段とを備えており、前記クライアントは、前記設定
手段により設定された内容に対応した編集情報を部分編
集情報として受信する要求を示す送信要求信号を前記サ
ーバへ送信する送信要求信号送信手段と、前記サーバか
ら送信されて来た前記部分編集情報を受信する編集情報
受信手段と、この編集情報受信手段により受信した部分
編集情報に基づいて所望の編集映像に対応する編集情報
を編集する編集手段とを備えたという技術的手段を用い
る。

【０００８】つまり、サーバは、編集情報記憶手段に記
憶されている編集情報のうち、どの部分を部分編集情報
としてクライアントへ送信するかを設定できるため、各
クライアントにより要求する編集情報の種類や内容が異
なることにより、サーバにおける編集情報の生成や管理
などの処理が複雑化することがない。

【０００９】請求項３に記載の発明では、請求項１に記
載の映像編集システムにおいて、前記サーバは、さら
に、前記編集情報記憶手段に記憶されている編集情報の
うち、どの部分を部分編集情報として前記クライアント
へ送信するかを設定した設定手段を有し、前記編集情報
送信手段は、前記編集情報記憶手段に記憶されている編
集情報のうち、前記設定手段により設定された内容に対
応した編集情報を部分編集情報として前記クライアント
へ送信するという技術的手段を用いる。

【００１０】つまり、サーバは、クライアントから送信
された送信要求信号により示される内容に対応した編集
情報を部分編集情報としてクライアントへ送信すること
ができ、あるいは、自身が設定した内容に対応した編集
情報を部分編集情報としてクライアントへ送信すること
もできる。したがって、クライアントは、サーバに設定
されている内容に従う場合は、送信要求信号の種類を状
況に応じて変更する手間を省くことができるし、サーバ
に設定されている内容に対応する編集情報が希望するも
のでない場合は、送信要求信号を変更することにより、
希望する編集情報をクライアントに送信させることがで
きる。

【００１１】請求項４に記載の発明では、請求項２また
は請求項３に記載の映像編集システムにおいて、前記編
集情報送信手段は、前記受信された送信要求信号の内容
に対応して複数種類の部分編集情報を送信可能であり、
前記サーバは、さらに、前記複数種類のうち、どの種類
を送信するかを前記受信された送信要求信号の内容毎の
受信頻度に対応して重み付けする重み付け手段を備えて
おり、前記設定手段は、前記重み付け手段による重み付
けに基づいて、設定されている内容を変更可能であると
いう技術的手段を用いる。

【００１２】サーバは、受信した送信要求信号の内容毎
の受信頻度に対応して重み付けし、その重み付けに基づ
いて、設定されている内容を変更できる。つまり、クラ
イアントにおいて特定種類の編集情報の使用頻度が高く
なり、それに合わせて送信要求信号の内容として同じ内
容が設定される頻度が高くなると、サーバは、その内容
に対応した編集情報の送信の優先順位を他の種類の編集
情報よりも高く設定するため、クライアントは、使用す
る頻度が高くなった編集情報を優先的に受信することが
できるので便利である。

【００１３】請求項５に記載の発明では、請求項１ない
し請求項４のいずれか１つに記載の映像編集システムに
おいて、前記編集情報送信手段は、前記部分編集情報の
中から、情報量の小さい順に選択して前記クライアント
へ送信可能であるという技術的手段を用いる。

【００１４】つまり、クリップの開始点および終了点を
示すデータなど、必ずしも情報量が多い画像データを送
信しなくても、映像の内容を特定できることが多いた
め、サーバは、情報量の小さい順に部分編集情報をクラ
イアントへ送信する。したがって、情報量の大きい部分
編集情報から送信する場合よりも、通信時間を短縮し、
かつ、通信コストを低減できる可能性を高めることがで
きる。

【００１５】請求項６に記載の発明では、請求項２ない
し請求項５のいずれか１つに記載の映像編集システムに
おいて、前記クライアントは、さらに、前記設定手段に
より設定されている内容の変更を要求する変更要求信号
を送信する変更要求信号送信手段を備えており、前記サ
ーバは、前記クライアントから送信された変更要求信号
を受信する変更要求信号受信手段と、この変更要求信号
受信手段が受信した変更要求信号により示される内容に
基づいて前記設定手段により設定されている内容を変更
する設定内容変更手段とを備えたという技術的手段を用
いる。

【００１６】つまり、クライアントは、サーバにおける
設定内容を変更したい場合には、変更要求信号をサーバ
へ送信することにより、上記設定内容を変更することが
できる。

【００１７】請求項７に記載の発明では、請求項１ない
し請求項６のいずれか１つに記載の映像編集システムに
おいて、前記サーバは、さらに、映像から編集情報を作
り出す編集情報生成部を備えたという技術的手段を用い
る。

【００１８】つまり、サーバにおいて編集情報を作り出
すため、クライアントにおいて編集情報を作り出す必要
がない。したがって、クライアントは、編集情報を作り
出すためのコンピュータプログラムを保有する必要がな
いため、汎用性があり、かつ、編集に必要なコストを低
減できる映像編集システムを実現できる。

【００１９】請求項８に記載の発明では、請求項７に記
載の映像編集システムにおいて、前記編集情報生成部
は、前記クライアントから送信された前記送信要求信号
を前記送信要求信号受信手段により受信した際に、前記
設定手段により設定された内容に対応する編集情報を生
成し、その生成した編集情報を前記編集情報記憶手段に
記憶するという技術的手段を用いる。

【００２０】つまり、サーバは、クライアントから送信
要求信号を受信した際に、設定内容に対応する編集情報
を生成するため、クライアントが要求していない場合で
あっても編集情報を生成しておく場合と比較して、編集
情報記憶手段における編集情報の記憶領域を効率的に活
用できるし、生成および記憶のための無駄な処理を省く
ことができる。

【００２１】請求項９に記載の発明では、請求項１ない
し請求項８のいずれか１つに記載の映像編集システムに
おいて、前記サーバは、さらに、前記クライアントから
送信された編集指示信号を受信する編集指示信号受信手
段と、映像を記憶する映像記憶手段と、前記編集指示信
号受信手段により受信された編集指示信号にしたがって
前記映像記憶手段に記憶されている映像から該当する映
像を編集し、編集済映像を前記クライアントへ送信する
映像送信手段とを備えており、前記クライアントは、さ
らに、前記編集手段による編集結果に対応した編集指示
信号を前記サーバへ送信する編集指示信号送信手段を備
えたという技術的手段を用いる。

【００２２】つまり、サーバが映像を記憶し、クライア
ントからの編集指示にしたがって該当する映像をクライ
アントへ送信するため、クライアントは、映像編集を行
うことができる。したがって、クライアントは、自身に
設けられた、あるいは接続された記憶装置に編集映像を
記憶することにより、編集映像の記憶された媒体を作成
することができる。

【００２３】請求項１０に記載の発明では、請求項９に
記載の映像編集システムにおいて、前記映像送信手段
は、前記該当する映像を前記サーバに接続された映像記
憶装置へ出力するという技術的手段を用いる。

【００２４】つまり、サーバは、該当する映像をクライ
アントへ送信するのではなく、自身に接続された映像記
憶装置へ送信するため、クライアントは、サーバから送
信された映像を記憶する必要がない。したがって、クラ
イアントは、サーバから送信された映像を受信するため
の通信コストがかからないとともに、受信した映像を記
憶するための記憶領域を確保しておく必要もない。ま
た、クライアントは、上記映像記憶装置に備えられた記
憶媒体（たとえば、ＤＶＤ−Ｒ、ＤＶＤ−ＲＷ、ビデオ
テープなど）をサーバから受け取ることにより、自身が
編集した映像を入手できる。

【００２５】

【発明の実施の形態】以下、この発明に係る映像編集シ
ステムの実施形態について図を参照して説明する。な
お、以下に示す各実施形態では、ビデオテープに記録さ
れた映像を編集し、その編集映像をＤＶＤ−Ｒに記録す
る場合を例に挙げて説明する。 ［主要構成および主要機能］最初に、この実施形態に係
る映像編集システムの主要構成および主要機能について
図１および図２を参照して説明する。図１は、映像編集
システムの主要構成をブロックで示す説明図であり、図
２は、図１に示す映像編集システムの主要機能をブロッ
クで示す説明図である。なお、図２においてブロックで
示す各機能は、ＣＰＵ（図示省略）がコンピュータプロ
グラムを実行することにより実現する機能を示す。ま
た、各記憶部は、ハードディスクやＲＡＭなどの記憶媒
体（図示省略）により機能する。

【００２６】図１に示すように、映像編集システム１０
は、サーバ２０と、サーバ２０とネットワーク１４を経
由して接続されたクライアント４０とから構成されてい
る。サーバ２０には、ビデオデッキ１１およびＤＶＤ(D
igital Versatile Disc)ライター１３が接続されてい
る。ＤＶＤライター１３は、ＤＶＤ−Ｒに映像および音
声を記録する機能と、ＤＶＤ−ＲまたはＤＶＤ−ＲＯＭ
を再生する機能とを有する。サーバ２０は、ビデオキャ
プチャカード２１と、記憶部３０と、ストリーム編集実
行部２２と、ネットワークＩ／Ｆ２３とを備える。記憶
部３０は、映像・音声ストリーム記憶部３１と、映像を
編集するための情報（以下、編集情報と略称する）を記
憶する編集情報記憶部３２とを備える。また、ネットワ
ーク１４は、公衆通信交換網およびインターネットを組
み合わせたネットワークである。

【００２７】ビデオキャプチャカード２１は、ビデオデ
ッキ１１により再生されたビデオテープ１２の映像およ
び音声を取込み、その取込まれた映像および音声は、ビ
デオキャプチャカード２１を操作するソフトウエアであ
るキャプチャカード操作部２４により、コンピュータに
より処理可能なストリームデータに変換され、映像・音
声ストリーム記憶部３１に記憶される（図２）。編集情
報を作成するソフトウエアである編集情報作成部２６
は、映像・音声ストリーム記憶部３１に記憶されている
映像・音声ストリームを用いて編集情報を作成し（図
２）、その作成した編集情報を編集情報記憶部３２に記
憶する。編集情報は、種類毎に所定の条件により重み付
けされ、階層化して記憶される（図１）。ストリーム編
集実行部２２は、ネットワークＩ／Ｆ２３を介してクラ
イアント４０から受信した編集指示にしたがって映像・
音声ストリーム記憶部３１に記憶されている映像・音声
ストリームを編集し、その編集された映像・音声ストリ
ームをＤＶＤライター１３によりＤＶＤ−Ｒに記録す
る。

【００２８】クライアント４０は、パーソナルコンピュ
ータ（以下、ＰＣと略称する）４２と、ディスプレイ４
３と、キーボード４４と、マウス４５と、ネットワーク
Ｉ／Ｆ４１とを備える（図１）。クライアント４０は、
データの送受信を行うソフトウエアであるデータ送受信
部５０（図２）により、サーバ２０に対して編集情報の
送信要求を示す信号（以下、送信要求信号と略称する）
を送信し、その送信要求信号により示される内容に対応
した編集情報をサーバ２０から受信する。この受信され
た編集情報は、編集情報の解読を行うソフトウエアであ
る編集情報解読部４８（図２）により解読され、その解
読結果は、ディスプレイ４３に編集画面を表示するソフ
トウエアである編集画面表示部４６により、ディスプレ
イ４３に表示される。また、上記解読結果は、編集内容
記憶部４９（図２）にも記憶される。

【００２９】編集画面操作部４７は、ディスプレイ４３
に表示された編集画面上で編集作業を行うためのソフト
ウエアであり、公知のソフトウエアである。たとえば、
その編集画面の表示形態は、たとえば米国のマイクロソ
フト社が開発したＯＳであるWindows（Windowsは、マイ
クロソフト社の登録商標）方式の表示形態である。この
表示形態によれば、マウス４５によりポインタを画面上
を移動させ、クリック操作するだけの簡単な操作によ
り、編集作業を行うことができる。その編集結果は、編
集内容記憶部４９（図２）に記憶され、編集指示作成部
４９（図２）は、編集内容記憶部４９に記憶されている
編集内容に対応した編集を行うようにサーバ２０に対し
て指示するための信号（以下、編集指示信号と略称す
る）を作成する。そして、サーバ２０のストリーム編集
実行部２２（図１）は、クライアント４０から送信され
た編集指示信号に従って映像・音声ストリーム記憶部３
１から映像・音声ストリームを読出して編集を実行す
る。

【００３０】［編集情報の種類］次に、編集情報の種類
について図３を参照して説明する。図３は、編集情報記
憶部３２に記憶された編集情報の種類を示す説明図であ
る。 （１）サムネイル画像３２ａ サムネイル画像とは、元の画像の大きさを縮小したもの
である。サムネイル画像は、周知のアルゴリズムにより
生成可能であり、たとえば元画像を低域フィルタを通し
て高周波成分を取り除いた後、画素を間引くことで画像
を縮小できる。ＭＰＥＧやＪＰＥＧのＩ−ｆｒａｍｅで
あれば、ＤＣ成分を抽出することで容易にサムネイルを
作成することができる。このため、画質（解像度）は元
画像よりも劣るが、映像の１コマを見ることができるた
め、映像の内容を十分に把握することができる。

【００３１】編集作業として、クリップ単位でのカット
や並べ替えを行うときは、クリップの繋ぎ目、つまりク
リップの先頭および末尾付近のフレームを見て判断する
ため、そのフレームのサムネイル画像を編集情報として
サーバからクライアントへ送信するのが望ましい。ま
た、通常のビデオ映像は、３０フレーム／秒であり、連
続した２つのフレームは、シーンの変わり目（クリップ
の境界）を除くと、あまり差がない。したがって、同じ
数のフレームのサムネイルを送信することを考えた場
合、連続したフレームよりも、ある間隔（たとえば１
秒）置きにフレームを送信した方が、クリップ全体を把
握するのに役立つ。また、データのサイズを小さくする
ことができる。たとえば、元画像が解像度７２０×４８
０ＲＧＢ形式（ＢＭＰ）のデータ量は、１，０３６，８
５４バイトであるが、７２０×４８０ＪＰＥＧ圧縮した
もので６７，２８９バイトであり、元画像のデータ量の
約６．５％となる。また、元画像の解像度を変え、３６
０×２４０としたＪＰＥＧ圧縮では２１，４７８バイト
であり、元画像のデータ量の約２．１％となる。さら
に、１８０×１２０ＪＰＥＧ圧縮では７，３９９バイト
であり、元画像のデータ量の約０．７％となる。

【００３２】（２）２値画像３２ｂ フルカラーの画像ではなく、白黒の２値画像をサムネイ
ルとして用いても、その画面を十分に認識することがで
きるため、映像の内容を十分に把握することができる。
単純なビットマップ画像で考えた場合、フルカラーで
は、１ドットに対して２４ビットのデータが必要になる
が、２値画像では、１ビットで済む。したがって、サム
ネイルのデータ量を１／２４に減らすことができる。ま
た、２値画像データを圧縮することにより、さらにデー
タ量を減らすことができる。２値画像は、各画素につい
て、その値が、あるしきい値より大きい場合には
「１」、値が小さい場合には「０」を割り当てることに
より生成できる。たとえば、カラー画像の場合は、ま
ず、グレースケールに変換する。ＲＧＢカラー画像をグ
レースケールに変換するには、各画素について以下の変
換式を作用させる。

【００３３】Y=0.299R+0.587G+0.144B 次に、上記グレースケールに対して、しきい値を設定す
るが、良好な（視認性の良い）２値画像を生成するため
には、上記しきい値の求め方が重要である。元々の画像
が２値のもの、たとえば白い紙に黒いインクで文字が書
かれているものなどは、輝度ヒストグラムには、２つの
ピークを生じることになるため、その中間点にしきい値
を設定すれば良い。一方、元々の画像が２値でない画像
は、最適なしきい値を求めることが難しいが、単純に、
対象とする画像の最大値および最小値の中間の値をしき
い値として２値化する。

【００３４】（３）画像の一部３２ｃ 画像の一部をトリミングしたデータをサムネイルとして
用いても、その画面を十分に認識することができるた
め、映像の内容を十分に把握することができる。つま
り、画像の一部に、その画像の内容を特徴付ける部分が
存在する場合は、その部分させ見ることができれば、そ
の画像が含まれているクリップの内容を知ることができ
る。図４は、画像の一部をトリミングする様子を示す説
明図である。同図に示すように、横ｎ（たとえば８０画
素）×縦ｍ（たとえば６０画素）により囲まれた矩形Ａ
を取り出して新たなビットマップ画像Ｂを生成する。こ
のとき、画像Ｂの解像度は画像Ａの数分の１（たとえば
１／４）となるが、その画像Ｂには、画像Ａの内容を特
徴付ける部分が含まれているため、画像Ａと比べて遜色
ない。しかも、データ量を数分の１（たとえば１／４）
に減らすことができる。画像の一部３２ｑは、図４に示
すように、トリミングにより切り出したい矩形Ａの情報
（ａ，ｂ，ｍ，ｎ）を与えることにより、元画像の内
で、矩形Ａの範囲に該当する画素のみを抽出することに
より生成できる。

【００３５】（４）線画３２ｄ フルカラーの画像あるいは２値画像ではなく、線画をサ
ムネイルとして用いても、その画面を認識することがで
きるため、映像の内容を十分に把握することができる。
線画は、２値画像の輪郭を取出したものであるため、２
値画像よりもデータ量を大幅に削減できる。また、線画
を生成できる部分が少ない（まばらな）場合には、チェ
ーン符号により極めて少ないデータ量で画像を表現でき
る。また、線画は、画像の２値化、辺縁の検出、細線化
の３ステップにより生成できる。

【００３６】（５）クローズド・キャプション（ＣＣ）
３２ｅ クローズド・キャプションは、ビデオ信号の２１番目の
走査線に埋め込まれている。そのクローズド・キャプシ
ョンとして、クリップの字幕を示すデータを用いること
により、クリップ中のシーンを特定できる。既存のＭＰ
ＥＧエンコーダには、ビデオのキャプチャ装置によりそ
の部分を取出し、ＭＰＥＧストリームに含める機能を持
つものがある。また、通常用いられているＭＰＥＧデコ
ーダは、上記部分を取出す機能を備えているので、それ
によりデータを抽出することで、クローズド・キャプシ
ョンを取出すことができる。

【００３７】（６）テープラベル情報３２ｆ ビデオテープの外見から読み取れる情報をテープラベル
情報として用いることにより、複数のビデオテープがあ
る場合にテープを識別できる。たとえば、次の情報をテ
キストデータにする。形式（ＭｉｎｉＤＶ、Ｈｉ８、Ｖ
ｉｄｅｏ８、ＶＨＳ、ＶＨＳ−Ｃなど）（８バイト以
内）、メーカー名（２０バイト以内）、品名（２０バイ
ト以内）、テープ長［分］（４バイト以内）、属性（Ｍ
Ｐ、ＭＥなど）（８バイト以内）、録画方法（ＳＰ、Ｌ
Ｐ、標準、３倍など）（８バイト以内）、ラベルシート
内容（２５６バイト以内）。また、各行には、改行コー
ド（２バイト）が入る。テープラベル情報３２ｆのデー
タサイズは、テープ１本のデータは最大３３８バイトで
あり、ビデオテープが１０本あるとしても合計３３８０
バイトである。これを６４ｋｂｐｓの通信帯域では、約
０．４秒で送信完了するため、データ量が小さいと言え
る。テープラベル情報３２ｆは、サーバ側の作業者が、
ビデオテープの外見から読取り、その読取った情報をテ
キストエディタなどにより入力してテキストデータを作
成する。

【００３８】（７）音情報３２ｇ 音声ストリームをＭＰＥＧ−Ａｕｄｉｏにエンコード
したものの先頭のある時間分を分割して保持する。たと
えば約３秒間分を分割して保持する場合は、オーディオ
フレームで割り切れ、かつ最も３秒に近い時間分を分割
して保持する。先頭のある時間分の音を聞くことによ
り、映像の内容を十分に把握することができる。 クリップの一部あるいは全体の平均の音量を示した
り、最小および最大音量を示したりすることで、そのク
リップの内容を類推することができる。たとえば、山間
の静かなところで景色を撮影した内容のクリップの後に
自動車レースを撮影したクリップが記録されているよう
な場合は、クリップ間で平均音量または最大音量がかな
り異なるため、それらの情報を知ることにより、クリッ
プの内容を類推できる。

【００３９】各クリップ毎の平均音量を示す場合は、１
６ビットサンプリングで音量を示すとすると２バイト、
８ビットサンプリングで示すと１バイトのデータサイズ
となる。ここに挙げたサイズは、クリップの長さに関わ
らず一定であり、データ量は非常に小さい。ただし、単
純に音量を平均化するだけでは、クリップの長さが長く
なるほど特徴を拾い出すのが困難になるため、クリップ
のごく一部だけを取出すようにする。各クリップの音量
情報３２ｓとしては、種々の情報が考えられるが、たと
えばクリップ内の全サンプルの音量を平均化してそのク
リップの音量の代表値とする。また、クリップの先頭ｎ
秒（たとえば３秒）分のサンプルの音量を平均化して
（あるいは最大値をとり）、そのクリップの音量の代表
値とすることもできる。さらに、クリップ内でサンプル
をｎ秒（たとえば５秒）ずつに分け、分けた部分につい
てそれぞれを平均化して（あるいは最大値をとり）、ク
リップ内での音量の分布を表すようにしても良い。この
場合、データ量は、クリップの長さ（秒）／５倍とな
る。さらに、先頭オーディオフレームの帯域の周波数分
割情報を作成しても良い。

【００４０】音のスペクトル 図５は、音の９個の帯域のスペクトルを示すグラフであ
る。横軸が周波数であり、縦軸が音のエネルギーであ
る。このグラフによれば、音の周波数特性（＝音の高
低）を視覚化することができ、音色を視覚的に把握する
ことができる。データの大きさは、１サンプルを４バイ
トで表すとすると、サンプリング周波数３２ｋＨｚのＰ
ＣＭデータ１秒分は、４バイト＊３２，０００＝１２
８，０００バイトとなるが、音のスペクトルの１帯域分
を４バイトで表すとすると、４バイト＊９＝３６バイト
で済むため、データ量を大幅に削減することができる。
音のスペクトルは、たとえばフーリエ変換やウェーブレ
ット変換などの周知の手法により求めることができる。

【００４１】（８）クリップの開始点・終了点３２ｈ クリップ単位の編集作業（たとえば、挿入、削除、複
写、並べ替えなど）を行う場合において、素材となるビ
デオ映像の内容を時間単位で把握できる場合は、各クリ
ップの開始点および終了点が分かれば、各クリップの長
さを求めることができるため、その求めた長さに基づい
てクリップの内容をそれぞれ特定できるので、クリップ
単位の編集作業を行うことができる。図６は、クリップ
の開始点・終了点を示すデータ構造の説明図である。１
つの開始点または終了点につき、時分秒をそれぞれ１バ
イトずつで表し、フレーム数を１バイトで表すため、計
４バイトのデータ量である。たとえば、素材となるビデ
オ映像の全体が１００個のクリップで構成されている場
合でも、開始点・終了点を示すデータ量の合計は４バイ
ト＊１００＋１バイト＝４０４バイトであり、データ量
は極めて小さい。

【００４２】ここで、クリップの開始点・終了点を検出
する手法の一例を図７を参照して説明する。図７は、サ
ーバ２０が編集情報としてのクリップの開始点・終了点
を検出する際の処理の流れを示すフローチャートであ
る。この手法は、予めクリップの切れ目としたい箇所に
ブランク画像（真っ黒な画面や真っ白な画面など）を１
０フレーム連続で挿入しておくことを特徴とする。サー
バ２０は、素材となるビデオ映像を構成するフレーム画
像を取得し（ステップ（以下、Ｓと略す）１２）、ブラ
ンク画像を検出すると（Ｓ１４：Ｙｅｓ）、ブランク画
像をカウントするカウンタのカウンタ値に「＋１」を加
算する（Ｓ１６）。続いてサーバ２０は、カウンタのカ
ウント値が「１０」に達するまでフレーム画像の取得か
らブランク画像の検出およびカウント値の加算を繰り返
し（Ｓ１２〜Ｓ１６）、カウント値が「１０」に達する
と（Ｓ１８：Ｙｅｓ）、その１０フレーム目のブランク
画像に対応する時間をクリップの切れ目として設定する
（Ｓ２０）。

【００４３】続いてサーバ２０は、ブランク画像のカウ
ンタをゼロリセットし（Ｓ２２）、次のフレーム画像が
存在する場合は（Ｓ２６：Ｙｅｓ）、再びＳ１２〜Ｓ２
２を繰り返す。また、サーバ２０は取得したフレーム画
像がブランク画像でない場合は（Ｓ１４：Ｎｏ）、ブラ
ンク画像のカウンタをゼロリセットし（Ｓ２４）、次の
ブラック画像を取得するまで待機する（Ｓ２６、Ｓ１
２、Ｓ１４）。また、クリップの開始点・終了点を検出
する他の手法として、録画日時の不連続点を検出する
手法（たとえば特開平１１−４６３３６号公報）。素
材のビデオ映像を先頭から一定時間毎に分割し、それら
の１つ１つを自動的にクリップとして設定する手法。こ
れは、経過時間毎にクリップ分けしたい場合に有効な手
法である。素材のビデオ映像の中に含まれるフェード
インまたはフェードアウトの箇所を検出し、その検出さ
れた箇所をクリップの切れ目に設定する手法。これは、
通常、フェードインまたはフェードインは、場面の変わ
り目に行うため、場面の変わり目毎にクリップ分けした
い場合に有効な手法である。この場合、前述のブランク
画像の検出と同じアルゴリズムを適用できる。サーバ
側の担当者がクライアントの希望に従って素材のビデオ
映像を見ながら１つ１つクリップを設定して行く手法。
これは、手間はかかるが、クライアントの意図しないク
リップ分けになることが少なくなるという利点がある。
また、他の手法で大雑把にクリップ分けした後にこの手
法を用いると、クリップ分けを効率良く行うことができ
る。

【００４４】（９）クリップ数・番号３２ｉ クリップ数は、クリップ開始点の数または終了点の数に
対応するため、前述のクリップ開始点・終了点を検出す
るアルゴリズムを実行することにより求められる。ま
た、クリップ番号は、クリップ開始点を検出したときに
付すことができる。最初に大雑把にクリップ数またはク
リップ番号を指定し、その後徐々に絞り込んで行くこと
により、希望するクリップを見付けることができる。

【００４５】（１０）フレーム数３２ｊ クリップ内のフレーム数から、そのクリップの長さを類
推できるため、クリップの長さにより、内容を把握でき
る場合に有効な手法である。また、記録した順序で送信
することにより、経過時間を知ることもできる。また、
２バイトで表現できるフレーム数は、２¹⁶−１＝６５，
５３５フレームであり、これは、フレームレートが３０
ｆｐｓであるとすると、約３６分間の長さに相当する
（６５，５３５／３０＝約３６）。したがって、総ての
クリップが約３６分以内であれば、全体が１００個のク
リップを表現するために必要なデータ量は、２バイト＊
１００＝２００バイトとなり、非常に小さなデータ量で
済む。フレーム数は、各クリップ内のフレームの数をカ
ウントアップして生成する。また、クリップ開始点・終
了点からクリップの時間を求め、その時間にフレームレ
ートを乗算することにより生成できる。

【００４６】（１１）シーンチェンジ点数３２ｋ 素材のビデオ映像の中において、どのくらいのシーンチ
ェンジ点があるかを把握している場合は、シーンチェン
ジ点数を指定することにより、編集作業を行うことがで
きる。

【００４７】（１２）動きベクトルｍ 画面のアクティビティが高い部分は、動きが多いので、
編集上、重要な場合であることが予測できる。また、ア
クティビティが極端に低い場面は、静止画であると考え
られるが、ビデオ撮影に失敗した部分であることも多
い。そこで、画面のアクティビティの高低を検出するこ
とにより、編集点を見付ける手法を用いることができ
る。ＤＶＤやデジタルカメラなどで適用されているＭＰ
ＥＧ(Motion Picture Experts Group) などの画像圧縮
方式では、フレーム間の動きベクトルを用いて圧縮を行
っているため、その動きベクトル情報を用いて画面のア
クティビティを表すことができるので、そのアクティビ
ティを画像の識別に用いることができる。

【００４８】図８（Ａ）は、画面の動きを示す矢印の説
明図であり、図８（Ｂ）は、動きベクトルの座標の一部
を示す説明図である。たとえば、編集画面においてサム
ネイルを表示すべき部分に、図８（Ａ）に示すように矢
印を表示する。これにより、画面がどちらの方向に、ど
の程度動いているかを示すことができる。たとえば、左
側の矢印により、画面が右上に動いていることが分か
り、その矢印よりも短い右側の矢印により、画面が奥行
き方向に速度を落として動いていることが分かる。ま
た、アクティビティの高低を、赤色から青色までのグラ
デーション（濃淡の段階的変化）で表し、それを矢印の
背景として用いることにより、映像のアクティビティを
感覚的に表すこともできる。

【００４９】データ量は、ＭＰＥＧの符号化単位である
ＧＯＰ(Group of Pictures) 毎に、数十バイトで表現で
きるので、極めて小さい。また、動きベクトルは、ＭＰ
ＥＧ圧縮されたストリームから取り出すことにより生成
する。ＭＰＥＧストリームのフォーマットは、ＩＳＯ規
格の１３８１８−２により規定されており、既存のＭＰ
ＥＧデコーダと同等の処理で動きベクトルを取り出すこ
とができる。ＭＰＥＧにおいては、ＰＢピクチャのＰＢ
マクロブックに動きベクトルが用いられる。Ｉピクチャ
（およびタイプＩのマクロブック）には動きベクトルは
存在しない。また、ＢピクチャのＢタイプマクロブック
には、後ろ向きの動きベクトルも存在するが、ここで
は、それを用いず、順方向のみの動きベクトルを使用す
る。このように、総てのフレームの総てのマクロブック
に動くベクトルが存在するわけではないので、動きベク
トルに関する処理は、ある単位長のデータについて計算
し、それを平均化して用いる。たとえば、単位長は、Ｍ
ＰＥＧのＧＯＰを用い、それを１５フレーム（３０ｆｐ
ｓにおいて０．５秒）とする。

【００５０】動きベクトルは、図８（Ｂ）に示すよう
に、各マクロブック毎の１組の座標として得られる。こ
れらのベクトル値から単位長の映像における動きベクト
ルの代表値を取出す手法を以下に示す。 動きベクトルの和を求める。各動きベクトルの和は、
動きベクトルの存在するマクロブックの数で正規化する
ので、平均値の計算を行って各動きベクトルの和を求め
る。これにより、画面全体がどの方向に動いているかを
示す代表的な動きベクトルを求めることができる。 動きベクトルの２乗和を求める。単純な和では、画面
の平行移動は検出できるが、たとえば回転の場合、単純
な和では結果が「０」になって動きを検出できない。こ
のように、単純な方向を取り出せない場合、大きさのみ
でアクティビティを求める。そのためには、各ベクトル
の長さの２乗和をブロック数で正規化して用いる。動
きベクトルの最大値を取出す。映像の一部のみに動きが
ある場合、意味のある動きベクトルを持つブロックはさ
ほど多くない。そのような場合には、ブロック数で正規
化すると、特徴的な値を取出すことができない。そこ
で、意味のある動きベクトルとして、最大の大きさを持
つ動きベクトルを代表値として採用すれば、上記の場合
に対応できる。また、これと同様の手法として、ブロッ
ク数の２０％までをベクトルの大きさの大きいものから
選択するという手法もある。さらに、この方法と、お
よびの手法を組み合わせて用い、総てのブロックのベ
クトルではなく、ベクトル値の大きいものに対して、和
や２乗和を求めてもよい。

【００５１】（１３）単色画像３２ｎ ある画面の中で最も多く使われている色や、全体を平均
化した色を代表色として画像の代わりに表示する。たと
えば、サムネイルを並べて表示する際、転送されていな
い部分を単なるブランクで表示するのではなく、画面に
関連のある色で表示することにより、映像の雰囲気が分
かる。特に、シーンの変わり目は単色画像のみでも識別
可能である。また、単色であれば、色の値をＨＴＭＬ(H
yper Text Markup Language)中に記述するだけでクライ
アント側のブラウザで表現できる。このとき、ＨＴＭＬ
に記述する際は、＃１２Ａ８４４のようにＲＧＢ形式で
記述するだけでブラウザに表示させることができるた
め、色データをそのまま送信する場合と比較してデータ
サイズは非常に小さい。具体的には、<table width="2
0" height="20" bgcolor="#FF0000"><tr><td></td></tr
></table>の計７４バイトでブラウザ内に２０×２０ピ
クセルサイズの赤い四角を表示させることができる。た
とえば、画像をＲＧＢ成分で解析し、ＲＧＢの分布から
最頻値または平均値を求め、単色を決定する。

【００５２】［主な処理内容］次に、サーバ２０および
クライアント４０が実行する主な処理内容を説明する。 （重み付け）最初に、サーバ２０が編集情報をクライア
ント４０へ送信する際に、どの編集情報を優先して送信
するかの順位を重み付けする手法について説明する。サ
ーバ２０の編集情報記憶部３２には、図３に示したよう
に各種の編集情報が記憶されているが、送信時の優先順
位は、図９に示す優先順位テーブル３２ｐにより決定す
る。優先順位テーブル３２ｐは、各クライアント毎に設
定されており、ユーザＩＤ（図９に示す例ではＵＳＥＲ
０００００１）と、優先順位と、クライアントからの要
求頻度と、クライアントへの送信回数とを対応付けて構
成される。図９に示す例では、優先順位１位がサムネイ
ルであり、その要求頻度は３８であり、送信回数は８７
となっている。優先順位は、要求頻度および送信回数に
基づく学習により入れ替わる。

【００５３】（サーバ２０およびクライアント４０が実
行する主な処理の流れ）次に、サーバ２０およびクライ
アント４０が実行する主な処理の流れについて図１１お
よび図１２を参照して説明する。図１１はサーバ２０が
実行する主な処理の流れを示すフローチャートであり、
図１２はクライアント４０が実行する主な処理の流れを
示すフローチャートである。サーバ２０は、ビデオデッ
キ１１（図１）により再生されたビデオテープ１２の映
像に基づいて前述した各種の編集情報を生成し、編集情
報記憶部３２（図２）に記憶する（図１１のＳ１０）。
また、クライアント４０が、編集情報の送信要求を示す
信号（以下、送信要求信号を称する）をサーバ２０へ送
信すると（図１２のＳ５００）、サーバ２０は、その送
信要求信号を受信し（図１１のＳ５０）、その送信要求
信号により示される内容に対応した編集情報（以下、部
分編集情報と称する）を編集情報記憶部３２から読出し
てクライアント４０へ送信する（Ｓ１００）。

【００５４】ここで、サーバ２０が図１１のＳ１００に
おいて実行する部分編集情報送信処理の流れについて、
それを示す図１４のフローチャートを参照して説明す
る。サーバ２０は、クライアント４０から送信要求信号
を受信したことを示す送信要求フラグをチェックし（Ｓ
１０２）、フラグがある場合は（Ｓ１０４：Ｙｅｓ）、
送信要求信号により示される内容に対応した部分編集情
報を編集情報記憶部３２から読出し、その読出した部分
編集情報をクライアント４０へ送信する（Ｓ１０６）。
続いてサーバ２０は、送信要求フラグをリセットし（Ｓ
１０８）、送信要求フラグをチェックするが（Ｓ１０
２）、Ｓ１０８においてリセットされているため送信要
求フラグなしと判定する（Ｓ１０４：Ｎｏ）。続いてサ
ーバ２０は、部分編集情報を送信中でない、つまり通信
回線が空いていると判定すると（Ｓ１１０：Ｎｏ）、部
分編集情報を送信する（Ｓ１１２）。

【００５５】なお、送信する部分編集情報がサムネイル
である場合は、前述のようにサムネイルは、箇所により
有用性が異なるので、１つのクリップ中では、クリッ
プの先頭、末尾のサムネイル。ある時間（たとえば１
秒）単位のサムネイル（これも先頭、末尾から中央に向
かって送信する）。他のサムネイル。また、クリップ
の送信順序は、自動では先頭から送信するが、クライア
ントの指示がある場合は、クライアントが最後に要求し
たクリップの優先順位を高くする。そしてサーバ２０
は、部分編集情報の終了を待たずに送信要求フラグをチ
ェックする（Ｓ１０２）。つまり、クライアントからの
送信要求に速やかに応答し、その送信要求に対応した部
分編集情報を送信する。仮に、クライアントからの送信
要求を検出した時点で、前記順位による方法に従って送
信中の情報がある場合には、その送信をキャンセルして
クライアントからの指示を優先させる。

【００５６】そして、クライアント４０は、サーバ２０
から送信された部分編集情報を受信し（図１２のＳ５５
０）、その受信した部分編集情報をディスプレイ４３に
表示し、キーボード４４およびマウス４５を用いて編集
作業を行う（Ｓ６００）。そして、クライアント４０
は、編集作業を終了すると、編集指示信号をサーバ２０
へ送信する（Ｓ６５０）。続いて、サーバ２０は、クラ
イアント４０から送信された編集指示信号を受信し（図
１１のＳ１５０）、ストリーム編集部２２（図２）は、
受信した編集指示信号に基づいて、映像・音声ストリー
ム記憶部３１から映像・音声ストリームを読出し、その
編集を実行し、その編集結果をＤＶＤライタ１３へ出力
する（Ｓ２００）。これにより、ＤＶＤライタ１３は、
入力した編集結果をＤＶＤ−Ｒに書き込み、クライアン
ト４０がビデオテープ１２を編集した内容が記録された
ＤＶＤ−Ｒが完成する。

【００５７】また、サーバ２０は、クライアント４０か
らの送信要求の頻度に対応して優先順位の設定内容を変
更する（図１１のＳ２５０）。ここで、サーバ２０が実
行する設定内容変更処理の流れについて、それを示す図
１３のフローチャートを参照して説明する。サーバ２０
は、クライアント４０から送信された送信要求信号を受
信すると（Ｓ２５２：Ｙｅｓ）、その受信した送信要求
信号により指定された編集情報に対応付けられている要
求頻度（図９）に所定値を加算し（Ｓ２５４）、ユーザ
情報を更新する（Ｓ２５６）。

【００５８】続いてサーバ２０は、所定値を加算した後
の要求頻度と、自身よりも優先順位の高い他の編集情報
の要求頻度とを比較し（Ｓ２５８）、上記要求された編
集情報の要求頻度よりも低い要求頻度の他の編集情報が
存在する場合は（Ｓ２６０：Ｙｅｓ）、上記要求された
編集情報と上記他の編集情報との優先順位を入れ替える
（Ｓ２６２）。つまり、クライアントの要求頻度を学習
により優先順位に反映させることができる。なお、ビデ
オテープ１本に対して１つのみ存在する編集情報から、
クリップ１つに対して１つのみ存在する編集情報、ある
いは各フレーム毎に１つ存在する編集情報まで存在する
ため、上記所定値は、編集情報により異なる。たとえ
ば、単色画像、２値画像および線画については、それぞ
れ所定値は「１」であり、音量および動きベクトルは、
それぞれ「１０」であり、クリップ開始点・終了点およ
びクリップ数・番号については、それぞれ「５０」とす
る。

【００５９】また、あるクリップの編集情報（たとえば
サムネイル）を送信中に他のクリップの同種の編集情報
がクライアントから要求された場合は、次の送信時に
は、前に送信していた編集情報ではなく新たに指定され
た編集情報を含むクリップの送信を開始する。さらに、
あるクリップの編集情報（たとえばサムネイル）を送信
中に、クライアントの編集作業により、その編集情報が
カットされた場合に、そのクリップの情報はもう必要な
いと考えられるので、送信を停止し、他の編集情報を送
信することができる。また、そのクリップが編集結果に
採用されることが確定した場合は、そのクリップの情報
が必要になる可能性は小さいので、その時点で、編集情
報の送信を停止することができる。なお、総てのフレー
ムに対するサムネイルは、ビデオ映像を送信することと
等しいため、優先順位から外すことができる。

【００６０】［実施形態の効果］ （１）以上のように、上記実施形態の映像編集システム
１０を使用すれば、クライアント４０は、映像を編集す
るために必要な編集情報をサーバ２０から受信し、その
編集情報により編集を行うことができるため、総ての映
像を受信する必要がない。したがって、従来のように、
クライアント４０が総ての映像を受信してから編集作業
を行う手法よりも、編集作業を行うことを決定してから
実際に編集作業を開始するまでにかかる時間を短縮する
ことができる。また、サーバ・クライアント間の通信時
間を短縮できるため、通信コストを低減することもでき
る。 （２）また、サーバ２０は、クライアント４０から送信
された送信要求信号により示される内容に対応した編集
情報をクライアント４０へ送信することができる。した
がって、クライアント４０は、サーバ２０から受信した
編集情報が希望するものでない場合は、送信要求信号を
変更することにより、希望する編集情報を受信すること
ができる。また、クライアント４０は、サーバ２０に設
定されている内容に従う場合は、送信要求信号の種類を
状況に応じて変更する手間を省くことができる。

【００６１】（３）さらに、サーバ２０は、編集情報の
送信の優先順位を送信要求頻度に対応して重み付けし、
その重み付けに基づいて、設定されている優先順位を変
更できる。つまり、クライアント４０において特定種類
の編集情報の使用頻度が高くなると、サーバ２０は、そ
の編集情報の送信の優先順位を他の種類の編集情報より
も高く設定するため、クライアント４０は、使用する頻
度が高くなった編集情報を優先的に受信することができ
るので便利である。 （４）またさらに、サーバ２０において編集情報を作り
出すため、クライアント４０において編集情報を作り出
す必要がない。したがって、クライアント４０は、編集
情報を作り出すためのコンピュータプログラムを保有す
る必要がないため、汎用性を高めることができ、かつ、
編集に必要なコストを低減できる映像編集システムを実
現できる。

【００６２】（５）そしてさらに、サーバ２０が映像・
音声ストリームを記憶し、クライアント４０からの編集
指示にしたがって該当する編集情報をクライアント４０
へ送信するため、サーバ２０は映像を記憶しておく必要
がない。したがって、サーバ２０は映像・音声ストリー
ムを記憶するための負担を軽減することができる。 （６）さらに、サーバ２０は、編集した映像をクライア
ント４０へ送信するのではなく、自身に接続されたＤＶ
Ｄライタ１３へ出力するため、クライアント４０は、サ
ーバ２０から送信された映像を記憶する必要がない。し
たがって、クライアント４０は、サーバ２０から送信さ
れた映像を受信するための通信コストがかからないとと
もに、受信した映像を記憶するための記憶領域を確保し
ておく必要もない。また、クライアント４０は、サーバ
２０からＤＶＤ−Ｒを受け取ることにより、自身が編集
した映像を入手できる。

【００６３】［他の実施形態］ （１）編集情報の組み合わせ 優先順位付けされる編集情報としては、上述した単独で
はなく、以下に示すように組み合わせて用いることもで
きる。この場合、特に組み合わせにより有用性が高くな
るが、データ量がそれほど増加しない組み合わせを用い
ると効果的である。 １つのクリップにおけるフェードイン点およびフェー
ドアウト点と、それらに対応するサムネイル２枚 この組み合わせによれば、クリップの内容の把握が容易
になる。 クリップ先頭のサムネイルおよび動きベクトル 動きベクトルのデータだけでは、有用性は低いが、クリ
ップ先頭のサムネイルを動きベクトルのデータに付加す
ることで、サムネイルおよび動きから画像を推測できる
ので、有用性を高めることができる。

【００６４】音情報および先頭のサムネイル 画像よりも音の方がデータ量が少ないので、画像は１枚
のみとし、他は音情報だけを送信することで、データ量
を減少させることができる。 単色画像および線画 単なる線画に、その画面を代表する色を付けることによ
り、クリップの内容を感覚的に分かり易くすることがで
きる。２値画像を白黒ではなく、代表色により表示して
も、同様の効果が得られる。 サムネイルおよび画像の一部 画像の一部を送信する場合、毎回送信する領域を指定し
ていては手間がかかるため、サムネイルとする領域を一
律に固定するのが自然である。なお、上記のように編集
情報を組み合わせる場合には、以前にどのような編集情
報が送信されているかにより、次に送信すべき編集情報
の優先順位付けを変えることが効果的である。たとえ
ば、クリップの先頭のサムネイルは、極めて有用性が高
いので、まずクリップの先頭のサムネイルを送信し、そ
の後、動きベクトルや単色画像、音情報などを送信する
ように制御することが望ましい。

【００６５】（２）クライアント４０において上記優先
順位を直接変更することもできる。図１０は、クライア
ント４０に設けられたディスプレイ４３（図１）の表示
内容を示す説明図である。図１０に示すように、ディス
プレイ４３に、編集情報の優先順位の学習状況を表示す
る。図１０に示す例では、優先順位が表形式で表示さ
れ、優先順位１位がフレーム数であり、２位がサムネイ
ルとなっている。また、表の下部には、上記学習をクリ
ヤーするか、保存するかを選択するチェックボックス
と、選択を確定するボタン（ｇｏ！！）とが表示されて
いる。優先順位の変更は、文字ボックス内に文字を入力
する、優先順位を示す数字を変更する、文字ボックスを
ドラッグして移動させるなどの手法により行うことがで
きる。また、マウス４５の操作によりクリヤーをチェッ
クし、ｇｏ！！を押すと、表示されている学習状況の内
容が消去される。また、保存をチェックし、ｇｏ！！を
押すと、表示されている学習状況の内容が保存される。
なお、クライアント４０において、優先順位の変更また
は消去の操作が行われた場合には、その操作に対応する
変更要求信号がサーバ２０へ送信される。つまり、クラ
イアント４０は、サーバ２０における設定内容を変更し
たい場合には、変更要求信号をサーバ２０へ送信するこ
とにより、上記設定内容を変更することができる。な
お、この構成を採用した場合の映像編集システムが、請
求項６に係る映像編集システムに対応する。

【００６６】（３）編集情報のデータ量の大小により、
編集情報の送信の優先順位付けを行い、編集情報記憶部
３２に記憶しておくこともできる。図１５は、データ量
の小さい編集情報を優先順位を高く設定した場合の説明
図である。つまり、フレーム数、クリップの開始点・終
了点を示すデータなど、必ずしも情報量が多い画像情報
などを送信しなくても、映像の内容を特定できる場合が
あるため、サーバ２０は、情報量の小さい順に編集情報
をクライアント４０へ送信する。したがって、情報量の
大きい編集情報から送信する場合よりも、通信時間を短
縮し、かつ、通信コストを低減できる可能性を高めるこ
とができる。なお、この構成を採用した場合の映像編集
システムが、請求項５に係る映像編集システムに対応す
る。

【００６７】（４）サーバ２０の編集情報生成部２６
は、クライアント４０から送信された送信要求信号を受
信した際に、設定内容に対応する編集情報を生成し、そ
の生成した編集情報を編集情報記憶部３２に記憶するよ
うに構成することもできる。この構成によれば、サーバ
２０は、クライアント４０から送信要求信号を受信した
際に、設定内容に対応する編集情報を生成すればよいた
め、クライアント４０が要求していない場合であっても
編集情報を生成しておく場合と比較して、編集情報記憶
部３２における編集情報の記憶領域を効率的に活用でき
るし、生成および記憶のための無駄な処理を省くことが
できる。なお、この構成を採用した場合の映像編集シス
テムが、請求項８に係る映像編集システムに対応する。

【００６８】（５）前述の実施形態では、サーバ２０か
ら編集映像および音声をサーバ２０に接続されたＤＶＤ
ライタ１３に出力する場合を説明したが、サーバ２０か
ら編集映像および音声をクライアント４０へ送信し、ク
ライアント４０に備えられた記憶装置あるいはクライア
ント４０に接続されたＤＶＤライタなどの映像記憶装置
に書き込むように構成することもできる。この構成によ
れば、編集映像および音声が記録された記録媒体をクラ
イアント４０において作成することができる。なお、こ
の構成を採用した場合の映像編集システムが、請求項９
に係る映像編集システムに対応する。 （６）前述の実施形態では、この発明に係る映像編集シ
ステムとして、１台のクライアント４０と１台のサーバ
２０とがネットワーク１４を経由して接続されている場
合を例に挙げて説明したが、複数のクライアントと１台
のサーバ、または１台のクライアントと複数のサーバ、
あるいは複数のクライアントと複数のサーバの組み合わ
せに対してもこの発明を適用できることは勿論である。

【００６９】［各請求項と実施形態との対応関係］サー
バ２０の編集情報記憶部３２が、請求項１に係る編集情
報記憶手段に対応し、データ送受信部２７が、送信要求
信号受信手段および編集情報送信手段に対応する。ま
た、クライアント４０のデータ送受信部５０が、請求項
１に係る送信要求信号送信手段および編集情報受信手段
に対応し、編集画面表示部４６、編集画面操作部４７、
編集情報解読部４８および編集内容記憶部４９が、編集
手段に対応する。また、優先順位テーブル３２ｐ（図
９）が、請求項２に係る設定手段に対応し、サーバ２０
の編集情報生成部２６が、請求項７に係る編集情報生成
部に対応する。さらに、サーバ２０のデータ送受信部２
７が、請求項９に係る編集指示信号受信手段に対応し、
クライアント４０のデータ送受信部５０が、編集指示信
号送信手段に対応する。またさらに、サーバ２０の映像
・音声ストリーム記憶部３１が、請求項９に係る映像記
憶手段に対応し、ＤＶＤライタ１３が、請求項１０に係
る映像記憶装置に対応する。

【００７０】そして、サーバ２０が実行するＳ５０（図
１１）が、請求項１に係る送信要求信号受信手段として
機能し、Ｓ１００が編集情報送信手段として機能する。
また、クライアントが実行するＳ５００（図１２）が、
請求項１に係る送信要求信号送信手段として機能し、Ｓ
５５０が編集情報受信手段として機能し、Ｓ６００が編
集手段として機能する。さらに、サーバ２０が実行する
Ｓ２５２〜Ｓ２６２（図１３）が、請求項４に係る重み
付け手段として機能し、Ｓ１５０（図１１）が請求項９
に係る編集指示信号受信手段として機能し、Ｓ２００が
映像送信手段として機能する。またさらに、クライアン
ト４０が実行するＳ６５０（図１２）が、編集指示信号
送信手段として機能する。

【図面の簡単な説明】

【図１】この発明の実施形態に係る映像編集システムの
主要構成をブロックで示す説明図である。

【図２】図１に示す映像編集システムの主要機能をブロ
ックで示す説明図である。

【図３】編集情報記憶部３２に記憶された編集情報の種
類を示す説明図である。

【図４】画像の一部をトリミングする様子を示す説明図
である。

【図５】音の９個の帯域のスペクトルを示すグラフであ
る。

【図６】クリップの開始点・終了点を示すデータ構造の
説明図である。

【図７】サーバ２０が編集情報としてのクリップの開始
点・終了点を検出する際の処理の流れを示すフローチャ
ートである。

【図８】図８（Ａ）は、画面の動きを示す矢印の説明図
であり、図８（Ｂ）は、動きベクトルの座標の一部を示
す説明図である。

【図９】優先順位テーブル３２ｐの構成を示す説明図で
ある。

【図１０】クライアント４０に設けられたディスプレイ
４３の表示内容を示す説明図である。

【図１１】サーバ２０が実行する主な処理の流れを示す
フローチャートである。

【図１２】クライアント４０が実行する主な処理の流れ
を示すフローチャートである。

【図１３】サーバ２０が実行する設定内容変更処理の流
れを示すフローチャートである。

【図１４】サーバ２０が実行する編集情報送信処理の流
れを示すフローチャートである。

【図１５】データ量の小さい編集情報を優先順位を高く
設定した場合の説明図である。

【図１６】従来から行われている動画の編集手法の一例
を示す説明図である。

【図１７】従来から行われている動画の編集手法の一例
を示す説明図である。

【図１８】従来から行われている動画の編集手法の一例
を示す説明図である。

【符号の説明】

１０ 映像編集システム １１ ビデオデッキ １３ ＤＶＤライタ（映像記憶装置） ２０ サーバ ３１ 映像・音声ストリーム記憶部（映像記憶手段） ３２ 編集情報記憶部（編集情報記憶手段） ３２ｐ 優先順位テーブル（設定手段） ４０ クライアント

─────────────────────────────────────────────────────

【手続補正書】

【提出日】平成１２年１０月２０日（２０００．１０．
２０）

【手続補正１】

【補正対象書類名】明細書

【補正対象項目名】００２４

【補正方法】変更

【補正内容】

【００２４】つまり、サーバは、該当する映像をクライ
アントへ送信するのではなく、自身に接続された映像記
憶装置へ送信するため、クライアントは、サーバから送
信された映像を記憶する必要がない。したがって、クラ
イアントは、サーバから送信された映像を受信するため
の通信コストがかからないとともに、受信した映像を記
憶するための記憶領域を確保しておく必要もない。ま
た、クライアントは、上記映像記憶装置に備えられた記
憶媒体（たとえば、ＤＶＤ−Ｒ、ＤＶＤ−ＲＷ、ＤＶＤ
−ＲＡＭ、ビデオテープなど）をサーバから受け取るこ
とにより、自身が編集した映像を入手できる。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 石本 関 名古屋市瑞穂区苗代町15番１号 ブラザー 工業株式会社内 (72)発明者 田川 典生 名古屋市瑞穂区苗代町15番１号 ブラザー 工業株式会社内 (72)発明者 市川 恭久 名古屋市瑞穂区苗代町15番１号 ブラザー 工業株式会社内 Ｆターム(参考） 5C053 FA14 FA24 FA30 JA30 KA01 KA24 LA11 LA14 5C064 BA07 BC10 BC16 BC20 BC25 BD01 BD08 5D110 CA05 CA06 CD02 CD05 CD15

Claims (10)

【特許請求の範囲】
1. 【請求項１】 サーバと、このサーバと通信可能なクラ
   イアントとを備えており、 前記サーバは、 映像を編集するための編集情報を記憶する編集情報記憶
   手段と、 前記クライアントから送信された送信要求信号を受信す
   る送信要求信号受信手段と、 この送信要求信号受信手段により前記送信要求信号が受
   信された場合に、前記編集情報記憶手段に記憶されてい
   る編集情報のうち、前記受信された送信要求信号により
   示される内容に対応した編集情報を部分編集情報として
   前記クライアントへ送信する編集情報送信手段とを備え
   ており、 前記クライアントは、 前記編集情報記憶手段に記憶されている前記編集情報の
   うち、どの部分を部分編集情報として受信するかの要求
   を示す送信要求信号を前記サーバへ送信する送信要求信
   号送信手段と、 前記サーバから送信されて来た前記部分編集情報を受信
   する編集情報受信手段と、 この編集情報受信手段により受信した部分編集情報に基
   づいて所望の編集映像に対応する編集情報を編集する編
   集手段とを備えたことを特徴とする映像編集システム。
2. 【請求項２】 サーバと、このサーバと通信可能なクラ
   イアントとを備えており、 前記サーバは、 映像を編集するための編集情報を記憶する編集情報記憶
   手段と、 この編集情報記憶手段に記憶されている編集情報のう
   ち、どの部分を部分編集情報として前記クライアントへ
   送信するかを設定した設定手段と、 前記クライアントから送信された送信要求信号を受信す
   る送信要求信号受信手段と、 この送信要求信号受信手段により前記送信要求信号が受
   信された場合に、前記編集情報記憶手段に記憶されてい
   る編集情報のうち、前記設定手段により設定された内容
   に対応した編集情報を部分編集情報として前記クライア
   ントへ送信する編集情報送信手段とを備えており、 前記クライアントは、 前記設定手段により設定された内容に対応した編集情報
   を部分編集情報として受信する要求を示す送信要求信号
   を前記サーバへ送信する送信要求信号送信手段と、 前記サーバから送信されて来た前記部分編集情報を受信
   する編集情報受信手段と、 この編集情報受信手段により受信した部分編集情報に基
   づいて所望の編集映像に対応する編集情報を編集する編
   集手段とを備えたことを特徴とする映像編集システム。
3. 【請求項３】 前記サーバは、さらに、前記編集情報記
   憶手段に記憶されている編集情報のうち、どの部分を部
   分編集情報として前記クライアントへ送信するかを設定
   した設定手段を有し、 前記編集情報送信手段は、前記編集情報記憶手段に記憶
   されている編集情報のうち、前記設定手段により設定さ
   れた内容に対応した編集情報を部分編集情報として前記
   クライアントへ送信することを特徴とする請求項１に記
   載の映像編集システム。
4. 【請求項４】 前記編集情報送信手段は、前記受信され
   た送信要求信号の内容に対応して複数種類の部分編集情
   報を送信可能であり、 前記サーバは、さらに、前記複数種類のうち、どの種類
   を送信するかを前記受信された送信要求信号の内容毎の
   受信頻度に対応して重み付けする重み付け手段を備えて
   おり、前記設定手段は、前記重み付け手段による重み付
   けに基づいて、設定されている内容を変更可能であるこ
   とを特徴とする請求項２または請求項３に記載の映像編
   集システム。
5. 【請求項５】 前記編集情報送信手段は、 前記部分編集情報の中から、情報量の小さい順に選択し
   て前記クライアントへ送信可能であることを特徴とする
   請求項１ないし請求項４のいずれか１つに記載の映像編
   集システム。
6. 【請求項６】 前記クライアントは、さらに、 前記設定手段により設定されている内容の変更を要求す
   る変更要求信号を送信する変更要求信号送信手段を備え
   ており、 前記サーバは、 前記クライアントから送信された変更要求信号を受信す
   る変更要求信号受信手段と、 この変更要求信号受信手段が受信した変更要求信号によ
   り示される内容に基づいて前記設定手段により設定され
   ている内容を変更する設定内容変更手段とを備えたこと
   を特徴とする請求項２ないし請求項５のいずれか１つに
   記載の映像編集システム。
7. 【請求項７】 前記サーバは、さらに、 映像から編集情報を作り出す編集情報生成部を備えたこ
   とを特徴とする請求項１ないし請求項６のいずれか１つ
   に記載の映像編集システム。
8. 【請求項８】 前記編集情報生成部は、 前記クライアントから送信された前記送信要求信号を前
   記送信要求信号受信手段により受信した際に、前記設定
   手段により設定された内容に対応する編集情報を生成
   し、その生成した編集情報を前記編集情報記憶手段に記
   憶することを特徴とする請求項７に記載の映像編集シス
   テム。
9. 【請求項９】 前記サーバは、さらに、 前記クライアントから送信された編集指示信号を受信す
   る編集指示信号受信手段と、 映像を記憶する映像記憶手段と、 前記編集指示信号受信手段により受信された編集指示信
   号にしたがって前記映像記憶手段に記憶されている映像
   から該当する映像を編集し、編集済映像を前記クライア
   ントへ送信する映像送信手段とを備えており、 前記クライアントは、さらに、 前記編集手段による編集結果に対応した編集指示信号を
   前記サーバへ送信する編集指示信号送信手段を備えたこ
   とを特徴とする請求項１ないし請求項８のいずれか１つ
   に記載の映像編集システム。
10. 【請求項１０】前記映像送信手段は、前記該当する映像
    を前記サーバに接続された映像記憶装置へ出力すること
    を特徴とする請求項９に記載の映像編集システム。