< 3/ 5>FAQ/Movie関連/Cinepak

English

★FAQ ★Movie関連

▲ 戻る｜進む▼

FAQ/Movie関連

Cinepak

音声だけのCinepakを途中から再生したい。

Ｑ)

シネパックデータを任意の位置から再生することは可能か？
可能ならどういった方法で行えるのか。
音だけの(画像データを持たない)シネパックデータでもそれは可能か？

の2点に関して教えてください。

Ａ)

シネパックデータを任意の位置から再生する方法は、メモリ上にある場合でかつ、音はなく、かつすべてキーフレームである条件で可能です。
できません。

Cinepakでムービーの繋ぎ目でポーズすると次のムービーの音が鳴ってしまう。

Ｑ)

シネパックの分割ムービーのつなぎめ(次にムービーが始まる直前)で、 CPK_Pause 関数でポーズをかけると、ポーズしている間 CPK_EntryNext で登録された次のムービーの音声が鳴ってしまいます。(ループする) ポーズを解除するとしばらくの間、音声がずれてしまいます。

Ａ)

問題点は２つあります。

１つ目は、CPK_Pause関数にはVer1.10以降戻り値を返すようにしており、正しくPauseできない場合、エラーコードを出力するようになっています。

＜ポーズ関数 CPK_Pause の仕様変更＞

旧仕様:戻り値なし。

新仕様:Bool 型の戻り値を返す。

TRUE	:コマンドが受け付けられた
FALSE	:コマンドは受け付けられなかった

次の場合に FALSE を返します。

ハンドル異常。
再生ステータス CPK_STAT_PLAY_TIME 以外でポーズしようとした。
再生ステータス CPK_STAT_PLAY_PAUSE 以外でポーズ解除しようとした。
次ムービへの以降中にポーズしようとした。

上記のエラーコードを必ずチェックするようにしてください。

２つ目は、ムービーの変わり目でこのCPK_Pause関数を実行すると、関数内では変わり目が判断できないので、1つ目のチェックを行っても同現象がおこる可能性があります。
CPK_Pause関数を実行する前に行う処理については Cinepakユーザーズマニュアルの「(11) 次ハンドルの登録の変更について」を参照してください。

シームレスブランチ時のポーズについて。

Ｑ)

現在再生中のムービーを Movie1、CPK_EntryNext で登録した次に再生するムービーを Movie2とします。

Movie2 が登録されている状態でポーズをかける時、Movie1 と Movie2 の両方にたいして CPK_Pause 関数を呼んでいるのですが、Movie1 を再生中 (Movie2 が再生される前)にポーズをかけると、Movie1 は TRUE を返し、 Movie2 はまだ再生してないため FALSE を返すのですが、正しくポーズできたかを判断するには、どの様な処理をすればよいのでしょうか。

Ａ)

CPK_Pause関数ですが、シームレスブランチを行う場合慎重に使用してください。実行前には必ずステータス取得関数(CPK_GetPlayStatus)で必ず再生中のものだけに対してCPK_Pause関数を実行してください。ですから上記のように両方に対して CPK_Pauseを実行しないでください。

そして、CPK_EntryNextを実行した場合は、CPK_EntryNext関数の次のハンドルの移行期間をチェックして、確実にMovie2がplay状態になるまで、CPK_Pause関数を実行しないでください。

CinepakのエラーCPK_ERR_SAMPLE_IDとは？

Ｑ)

シネパックのエラーコード CPK_ERR_SAMPLE_ID (0x00000401)は、マニュアルに "ムービ識別子が異常"と記述されていますが、このムービー識別子とは何の事なのでしょうか。

また、シネパックの再生で、"FLOP"初期値が小さすぎるといったエラー (エラーコード0x301)が発生したのですが、"FLOP"とは何でしょうか。また大きくするにはどうすればよいのでしょうか。

Ａ)

リングバッファ内に取り込まれたデータがCinepakデータではない場合にこのエラーコードを出力します。
これはCD-ROMからリングバッファに対してデータが送られたときではなく、実際に展開処理を行う時に出力されるエラーです。

このエラーコードが出力されるケースとして、

CDから正しいデータファイルをロードしていない。
リングバッファの中身が他の処理中に壊されている。

などが考えられます。

ステレオ/モノラルの設定のついて教えてください。

Ｑ)

シネパック再生のステレオ、モノラルの切り替えはどうすればいいのでしょうか

Ａ)

シネパック再生のステレオ/モノラルの切り替えはサウンドドライバ側でコントロールするようにしてください。

CPK_SetPanという関数がありますがこれはいわゆる、左右のバランスに当たります。従ってシネパックのサウンドのステレオ/モノラルにするものではありません。

シームレスブランチをする際バッファはムービーの数だけ用意するんですか？

Ｑ)

ムービーのシームレスブランチ再生を行う場合、再生するムービーの数だけバッファを用意する必要がありますか？

例えば、A、B、C、３つのムービーをシームレスで再生する際、AとCを同じバッファで共有できないのでしょうか。

Ａ)

バッファはあくまでバッファでしかありませんから、複数のムービーを使用するからといって再生するムービーの数だけバッファを用意しなければいけないというような事はありません。
ですので、使っていないバッファがあればそれを使い回すという事は可能です。

CinepakをPALで正しく再生するには？

Ｑ)

NTSCで正常に再生されているシネパックを、PALで再生した際、サウンドが一瞬途切れたり、音と映像がずれるといった症状がおこります。
PALで正しく再生するには、どのようなことをすればよいのでしょうか。

Ａ)

このような現象は、Cinepakのデータ転送が間にあっていないために起こっています。
プログラム側で行う方法として

CPK_Taskの回数を増やす。
(PALは1/60から1/50にV-Blankの回数が減っているので、単純に増やしてみる)
CinepakライブラリVer1.10から対応したSlave CPUを使用するモードで実行する。
(アプリケーションでSlave CPUを使用していると、Cinepakライブラリが誤動作する可能性があります。)

の２つが考えられます。
今回のトラブルの場合、(1)の対応でクリアする可能性があります。実際1/60から1/50への変更(NTSCからPALへの)でタイミングの違いによって御社のような症状がでています。

プログラム変更による対応としてグラフィックスの転送タイミングや転送方法のを変更することが考えられます。

その他はデータをPAL用に修正して対応することが考えられ、修正方法としてはコマ落としやキーフレームを変更(30〜25など)することが考えられます。

シームレスブランチをする際のムービー登録のタイミングは？

Ｑ)

ムービーのシームレスブランチ再生を行う場合について質問です。
サンプル(smpcpk5.c)では2つのムービーを連続再生していますが、３つ以上のムービーを再生する場合、3つ目のムービーの登録[CPK_EntryNext()] はどのタイミングで行ったらよいのでしょうか？

      >    /* ムービ開始 */
      >    CPK_Start( cpk[0]  )  ;
      >
      >    /* 次に再生するムービの登録 */
      >    for ( i = 1 ; i < FILE_MAX ; i++ )
      >    {
      >          CPK_EntryNext( cpk[i] ) ;
      >    }

と、いったようにするのではないようですので、2番目のムービーが再生開始したら登録する場合、1番目のムービー終了を検知し、その後 CPK_EntryNext を発行するといった動作になるのでしょうか？

Ａ)

上記の方法で問題はないと思います。
3つ以上のムービーを次々にエントリしていく場合はリングバッファを2つ用意してバッファを切り替えていくのが効果的でしょう。

エラー処理はどのような点に注意すればよいでしょうか。

Ｑ)

エラー処理はどのような点に注意すればよいでしょうか。

Ａ)

ムービ再生中に、ファイルシステム，またはストリームシステムでエラーが発生すると、それ以降ムービの再生が継続できません。
この場合はムービハンドルを消去しファイルをクローズしてください。その後、再度ムービを再生する等の処理を行ってください。

各エラー処理関数 GFS_SetErrFunc、STM_SetErrFunc、CPK_SetErrFunc は必ず設定し、エラー検出をしてください。デバッグ効率も向上します。

データ転送にSCU-DMAを使用する時の注意事項はありますか。

Ｑ)

CDブロックから、リングバッファへのデータ転送にSCU-DMAを使用する場合の注意事項はありますか。

Ａ)

CDブロックからリングバッファへのデータ転送をSCU-DMAで行う場合、ペリフェラル情報が正しく得られなくなることがあります。
この場合、最大転送セクタ数(デフォルト値 20)を小さく設定することで改善できますが、小さい設定をした場合、それに見合う十分な頻度でタスク関数をコールする必要があります。

［処理例］

CPK_SetTrModeCd(cpk, CPK_TRMODE_SCU); /* SCU-DMAで転送する */
CPK_SetLoadNum(cpk, 10);              /* 1回の転送量の最大値 [sector]*/

また、SCU-DMAで転送中は使用するバスが占有されるので、SH2はCPUバスをアクセスしようとしたときからウエイト状態になってしまいます。
SCU-DMAは、極力使用しないでください。

フレームサイズとCinepakの圧縮方式の関係について教えてください。

Ｑ)

フレームサイズとCinepakの圧縮方式の関係について教えてください。

Ａ)

Cinepak は、フレームサイズ(面積)に応じて、1フレームを1〜3つに分割して圧縮処理を行います。

分割される条件の前後では、内部的な圧縮効率と画質が不連続になり、以下のような傾向があると考えられます。

分割条件より小さく、分割条件に近い場合：

画質が悪い (圧縮率が少し良い)

分割条件より大きく、分割条件に近い場合：

画質が良い (圧縮率が少し悪い)

正確な分割条件は不明ですが、確認した範囲を次に示します。

面積 [pixel]	フレーム分割数(タイル数)
96000 = 480×200 以上	3
95744 = 352×272 以下 59904 = 208×288 以上	2
57344 = 256×224 以下	1 (分割しない)

※シネパックライブラリが対応しているのは、２分割以下です。

画像伸張処理の効率いい処理方法はどうすれば良いのでしょうか？

Ｑ)

画像伸張処理の、効率のよい処理方法はどうすれば良いのでしょうか？

Ａ)

画像伸張処理は直接VRAMに出力するより、WORK RAM-Hに出力する方が効率が良いのでこの方がタスク関数は高速に動作します。
一旦 WORK RAM-H へ出力してSCU-DMAでVRAMに転送した方が、転送時間を加えても短い処理時間になります。

非圧縮ムービーを作りたい。

Ｑ)

非圧縮のムービーを表示させたいのですが。

Ａ)

(1) 非圧縮モードの使用条件
画像サイズやフレームレートを抑え、画質を優先させたい場合に利用します。

15ビット色のムービーには対応していません。24ビットのデータの 32K色表示には対応していますが、クオリティの高いデータを無駄にすることになります。

非圧縮の QuickTime Movie を MovieToSaturn_J でコンバートします。非圧縮ムービーの再生のために追加された関数はいっさいありません。
ファイルヘッダを解釈して処理するので、全く同じ手続きで再生できます。ただし、リングバッファだけは圧縮した場合より大きく確保しなければなりません。

(2) リングバッファサイズ
リングバッファは次の条件を満たすように確保する必要があります。

　ring ≧ header + sound + frame

ring :リングバッファサイズ
header :ファイルヘッダサイズ(セクタサイズバウンダリに切り上げ換算)
sound :サウンド0.5秒分のサイズ
frame :1フレーム非圧縮サイズ

(3) 動画性能
CDからのデータ転送レートから、次に示す程度の動画性能になります。

オーディオの条件限界動画性能

44kHz、16bit ステレオ
320×224[dot]　0.60[fps]

22kHz、 8bit モノラル
320×224[dot]　1.32[fps]

ビデオのみムービー
320×224[dot]　1.42[fps]

ビデオのみムービー
160×112[dot]　5.71[fps]

オーディオの条件	限界動画性能
44kHz、16bit ステレオ	320×224[dot]　0.60[fps]
22kHz、 8bit モノラル	320×224[dot]　1.32[fps]
ビデオのみムービー	320×224[dot]　1.42[fps]
ビデオのみムービー	160×112[dot]　5.71[fps]

デバッグ用実行の履歴出力について教えてください。

Ｑ)

デバッグ用実行の履歴出力について教えてください。

Ａ)

シネパックライブラリの主要な処理の実行履歴を出力すると、スムーズに再生できないなどの動作不良がある場合、原因究明に役立ちます。タスクのコールを定期的に行っているか、データの供給が滞っていないか、コマ落ちが発生していないかなどを調べることができます。

動作不良の再現性を確認してから、よりシンプルな実行履歴を作ったほうが履歴の解析か容易になります。
なお、この機能はSIMM領域に対して結果を出力します。したがって、 SIMMのささらないCartDev + DevSaturnでは動作しません。
その場合、 SIMMの使えるタイプのバッファカードを別途購入する必要があります。

［履歴を出力するシネパックライブラリの内部処理］

エラー発生時
タスク関数のコール時
リングバッファデータ供給時と消費時
表示要求フラグのOn/Off時
コマ落とし処理PCMスタート/ストップ

［出力の指定］

本番用のプログラムをそのまま使用する場合
CPK_Init の処理後にブレークします。リンク時に作成されるマップファイルで、CpkdSys 型の構造体 cpkd_sys のアドレスを調べ、デバッガのコマンドでcpkd_sys.mode の値を 0x00000001 に設定してください。

例. E7000／EVAボードのコマンドラインからの操作

:m 060XXXXX 1;l

出力アドレスは、0x04000000 〜 0x047fffff になります。
(Programming BoxのSW2-5<SIMMCART>をOFFにしてください。)
デバッグ出力するプログラムを作成する場合
CPK_Init のあとで CPKD_SetMode(ON) とします。CPKD_SetPrintAddr により、出力アドレスの設定ができます。CPKD_PrintStr 及び CPKD_PrintDataにより、アプリ側の処理の実行履歴を追加して出力することが可能です。

追加出力する場合、履歴情報を読みやすくするために出力するサイズは 164byteの整数倍にしてください。

［出力情報の確認］

出力アドレスをデバッガのコマンドでダンプ表示します。表示内容をテキストファイルとして保存し、テキストエディタで見ると動作の解析が容易になります。

例. E7000／EVAボードのコマンドラインからの操作

:> hist.txt [RET]
:d 04000000 04001000;l [RET]
:>- [RET]

［出力情報のフォーマット］

--------+--------------------------------------------+
ADDRESS : 0 1  2 3   4 5  6 7   8 9  A B   C D  E F  :
--------+--------------------------------------------+
04000000: AAAA_AAAA  ---- ----  ---- ----  ---- ---- :
04000010: "Err "     ---- VVVV  ---- ----  EEEE_EEEE :Error 
04000020: "Task"     PPPP VVVV  HHHH_HHHH  CCCC_CCCC :start of CPK_MeTask
04000030: "RWri"     WWWW VVVV  HHHH_HHHH  DDDD_DDDD :WRIte Ringbuffer
04000040: "RRea"     RRRR VVVV  HHHH_HHHH  DDDD_DDDD :REAd Ringbuffer
04000050: "DOn "     FFFF VVVV  LLLL_LLLL  TTTT_TTTT :set Disp flag On
04000060: "DOff"     FFFF VVVV  HHHH_HHHH  TTTT_TTTT :set Disp flag Off
04000070: "PcmS"     MODE VVVV  HHHH_HHHH  ADDR SIZE :PCM Start
04000080: "PcmE"     MODE VVVV  HHHH_HHHH  ---- ---- :PCM Stop
04000090: "LosF"     FFFF VVVV  LFLF_LFLF  SSSS_SSSS :LOse Frame
                              :
                              :

［出力情報の内容説明］

AAAA_AAAA :

現在の履歴情報出力アドレス。

---- VVVV :

Vblカウンタ。おおよその時刻がわかる。

EEEE_EEEE :

エラーコード。

PPPP ---- :

再生ステータス [-1, 0, 1, 2, 3, 4, 5]。

HHHH_HHHH :

シネパックハンドル。

CCCC_CCCC :

シネパックタスクコールカウンタ。

DDDD_DDDD :

リングバッファのデータの残量 [byte]。供給が滞ってないかわかる。

WWWW ---- :

リングバッファへの書き込みサイズ [sector]。

RRRR ---- :

リングバッファからの読み取りサイズ [byte]。

FFFF ---- :

フレーム番号。

LLLL_LLLL :

遅延時間。(現在時刻 − フレーム表示時刻)

TTTT_TTTT :

フレーム時刻。(フレーム表示時刻＋フレーム表示持続時間)

LFLF_LFLF :

コマ落ちカウンタ。

SSSS_SSSS :

サンプルカウンタ。

MODE ---- :

0x80##:ステレオ，0x10##:8bit，0x##03:PCMストリーム再生番号3
(PCM Stop の場合は、PCMストリーム再生番号だけ表示)

ADDR ---- :

PCMバッファスタートアドレス(4bit右シフト値)

SIZE ---- :

PCMバッファサイズ [sample/ch]

ムービーの再生情報の再生時間フィールドが示す数値が本来の再生時間と違う。

Ｑ)

ムービーオブジェクトの再生情報の再生時間フィールドが示す数値が本来の再生時間と違っています。どうしてでしょうか。

Ａ)

QuickTimeではムービーの時間管理をタイムコードより細かいTimeScaleという単位で行います。最大600分の1秒の精度まで管理できます。

通常、市販のアプリケーションは最大精度の1/600秒を使用します。
Author EditorもTimeScaleを600と想定して動画を扱います。
ただし、 Adobe Premiereなどアプリケーションによっては必ずしもTimeScaleを600と固定していません。

従って、でき上がったムービーが、TimeScaleを600として扱っていない場合、再生時間(QuickTimeでは DurationTimeと呼んでいる)が違って見えます。
(但し、再生にはなんら影響はありません。)

下に例を示します。

＜例：30秒のCinepakムービーを作った場合＞

	TimeScale	TimeCode	DurationTime
1.	600	00:00:30:00	18000	通常のムービー
2.	30	00:00:30:00	900	TimeScaleが30のムービー
3.	20	00:00:30:00	600	TimeScaleが20のムービー

※時間管理の単位が違うというだけで、 TimeScaleとDurationTimeの整合性は取れているので、上の3つのムービーはすべて見掛け上なんら違いのない正真正銘の折り目正しいムービーであることに注目！！
TimeScaleが30のムービーを AuthorEditorが読み込んだ場合、DurationTimeが指し示している数値900を参照して次のように再生時間を計算します。

　900÷600=1.5

よって、本来は30秒の再生時間を1.5秒と勘違いしてしまいます。

【対策】

ムービーの TimeScaleがいくつかを調べるのには、 Dumpster (QuickTime Developer's Kitに含まれる )を使います。
Dumpster を起動して対象のムービーを開きます。
ここで参照できる数値のうち、TimeScaleが600以外の数値を示していたらそれを600に修正します(複数箇所あるのですべて直します)。

さらにDuration, Track Dur, sampDurを TimeScaleの変更と整合が取れるように直します。(これらも複数あるものはすべて直す)修正が終わったらSaveして終了します。

【追記】

ムービーTimeScaleの数値の決定要因がどこにあるのかは、現在調査中でよくわかりません。現在わかっていることは、 Adobe Premiereを使って Cinepakムービーを作った場合にはTimeScaleが 600以外の数値になっていることが多いということです。

その外の圧縮ツール(MovieConverter, ConvertToMovie, Movie Conversion, MovieShop, CoSA AfterEffects等)では確認した限りでは 600の値を必ず示していました。

従って、どうしてもPremiereを使わなければいけないという必然性がなければその外の圧縮ツールを使って本障害を回避するのが一番よい方法でしょう。

▲ 戻る｜進む▼

★FAQ ★Movie関連