CC 2017 でMacでProRes422シーケンスから同じ設定のProResムービーを書き出すと赤いフレームが頻発する

[wb-ks]

環境=Mac Pro (Late 2013)・メモリ 48 GB 1866 MHz DDR3・MacOS10.12.2

Premiere Pro CC2017にアップデートしてからずっとこの問題に悩まされてきました。

Adobeさんなんとかしてください！

まず、私のワークフローですが、撮影素材はAVCHD・GOPRO・XDCAM EX・HDCAMテープを取り込んだProResファイル等を

1080サイズのレンダリング設定をProResにしたシーケンスに乗せて編集作業をしております。

そして、完成したらクライアント試写はmp4に書き出して修正箇所のやり取りをして最終完パケをProResで書き出します。

このProResムービーがデータ納品用・Blu-rayオーサリングのソース・保存用・HDCAMテープへのマスタリングソースになります。

このとき書き出し設定は「シーケンス設定を一致」にチェックそ入れ、「プレビューを使用」にチェックそ入れてメディアエンコーダーにキューします。

シーケンスのレンダリングは終了しているので、メディアエンコーダーのエンコーディング画面には映像は表示されず高速で書き出しが終わります。

いわゆるFCP的なワークフローでシーケンスのレンダリング設定を最終完パケムービーと同じコーデックにする事で編集中のモニタリングで

常に最終画質を確認しながら作業でき、納期的に厳しいときでも再エンコードなしで高速で書き出せるという方法です。

ところが、2017（2017.0.1・2017.0.2含む）で書き出し先を高速なRAIDやSSDにするとProResのmovファイルを正しく書き出せないようで

書き出したファイルをPremiereに読み込んで再生すると、無作為に一瞬赤いフレームが入るところが存在するのです。

問題のファイルをQTプレーヤーで見てみると、その部分がコマ飛びしていたり、画面が乱れたりしていて正常な書き出し結果では無い事が確認出来ます。

結論としては、ファイル書き出しの速度が200〜250MB/秒を越えるとこの症状が現れる可能性が高いようです。

それに気がつくまであらゆる可能性を探りましたが、主にSAS RAID（3TB24発RAID6）で作業をしていた為、

Mac初期化やOSのアップデート（10.11→10.12）もしましたが直りませんでした。

たまたま単体のHDD（150MB/秒程度）へ2時間のシーケンス3種類を書き出し、クライアント試写の前に全部見た所ノイズ等はなかったのですが

一部1ヶ所テロップを修正するはめになったので、再度書き出したファイルをもう一度全部見る事に。。。

試写当日もクライアントと一緒に全部見る事になりましたが問題無く納品出来ました。

そこで書き込み速度に注目をし、SSD（平均約300MB/秒）とRAID（平均約400MB/秒）同じシーケンスから書き出したところ

当該の問題が発生しました。

単体のHDD（先程とは別の個体複数）でテストをしましたが今のところ問題は無いようです。

問題の改善は当然ですが、せっかくムービーを再生中に損傷があるフレームを赤画面で表示する仕様になっているのに、それでスルーされる所が困りものです。

Premiere側でフレームが欠落している事を認識しているわけですから、赤画面発生時にせめて警告を出すとかTC付のログが残るとかしてもらいたいです。

[Ckun]

（先に、解決策の返信ではないことをお詫びいたします。）

プロダクション的に最も確実でスムーズであるはずのワークフローでトラブルが起きているようですので、心中お察しいたします。試写の度に胸が苦しく寿命が縮む思いをなさっているかと思います（私ならストレスで胃痛を起こすレベルです…）。

さて、レンダリング済みのタイムラインを再生しても赤いフレームや乱れは無く、そのタイムラインを再エンコードなしで書き出したファイルに乱れがあるとのことなので、(AME内部処理の)単純なファイルコピーの過程でデータ化けが起きていると考えられます。

CC2017にしてから問題が起きていることや、様々な状況で検証なさってる結果から、Adobe製品側の問題である可能性が高いように思いますが、強いて他の要因を挙げるならば、プレビューファイルの保存先から最終書き出しメディアへの経路（メディア自体のほかSASやS-ATAなどなど）で、高負荷時にデータ破損が起きていることも考えられそうです。

編集機が空く時間帯があれば、レスパスビジョンさんのRapidCopyのようなエラーチェック有りのファイルコピーツールを使用して、プレビューファイルの保存先のドライブから適当なデータ（2時間番組のプレビューファイル丸ごとなど）を書き出し先ドライブにコピーさせて、データ破損が一切ないことを確認してみてはいかがでしょうか。コピー中のCPUに負荷をかけるために、PremiereProで適当な素材をループ再生させるなどしておくと良いかと思います。

Adobeのソフトウェア以外に原因が考えられないところまで突き詰めれば、日本のAdobeサポートさんから海外技術部門に問い合わせてくれると思います。逆に言うと、そこまでユーザ側で検証しないとなかなか本腰をあげて対応してくれないという印象があるのですが、月々5千円のプランではコスト的に仕方ないことだと理解はしております。

デコードエラーの箇所を赤いフレームで埋める仕様の件は今回の書き出しファイル破損と直接の関係は無いと思いますが、おっしゃるとおり使い物にならない状況になるので、勝手に赤くして処理を進めるくらいなら、エラーダイアログを出して処理を止めてくれた方がありがたいくらいですね（以前に比べ、XDCAM素材のデコードエラーは出にくくなっているらしいですが……）。

[wb-ks]

Ckunさん　ご理解いただいて感謝します。

先週の睡眠時間はこのせいでほとんど削られました（笑）

FCPから乗り換えたCC2014からこのワークフローで作業をしており、会社やマシンは変わっていますが

こんな状況は初めてです。

グローバルFXミュート機能とショートカットキーの強化につられて今回はわりと早いタイミングでCC2017に移行してしまいました。

思えばCC2015の時もCC2015.3の時ももうちょっと様子をみてからバージョンアップしていました。。。

レスパスビジョンさんのRapidCopy結構便利そうですね!

当方はCarbon Copy Clonerで作業スペースのRAIDからバックアップ用ローカルHDDにプロジェクト別にバックアップをとっておりますが、今のところ問題は無いようです。

時間をみて高負荷時のコピーをテストしてみたいとおもいます。

＞レンダリング済みのタイムラインを再生しても赤いフレームや乱れは無く、

＞そのタイムラインを再エンコードなしで書き出したファイルに乱れがあるとのことなので、

＞(AME内部処理の)単純 なファイルコピーの過程でデータ化けが起きていると考えられます。

私も全く同じ見解です！

他の案件でもRAID内で書き出しまで完結するケースがほとんどなので、最初はRAIDシステムを疑ってもみたのですが

thunderbolt接続のSSDでも同じ現象が出たので、AMEが書き込み速度に追いついていないのではと考え

現在、別の20分程度のプロジェクトで同じようにRAID内とthunderbolt SSDとUSB外付けHDD試したところ、

5回検証してUSB HDDのみ5回ともOKで、RAIDは2回、SSDは3回NGでした。

最初に例に出した2時間番組は7カメパラ取りでしたので、マルチ画面を作成し書き出しており、

そのときはレンダリングせず、複数のシーケンスをAMEで一晩かけて書き出しています。

こちらの段積みの一番上にのせてカメラ割りをしたのですが、マルチ映像には一切ノイズはありませんでした。

そこで最終的に、確実な方法として再エンコード無しは一旦あきらめて、

プレビューは使用するが同じコーデックで再エンコードする設定でしばらく行くことにしました。

具体的にはシーケンスと同じProResコーデックを選択し、「プレビューを使用」にチェックをいれ

書き出し設定のエフェクトでLumetri Look/LUTのチェックを入れて「適応=なし」という状態で書き出せば

プレビューファイルを利用しつつ強制的に再エンコード出来ます。

（最初はタイムコード表示をオンにして画面の外に置いてしまうという方法を試しましたが気分的に危険な感じがしたので・・・）

現在、問題のあった時と同じRAIDボリューム内での書き出しを6回テストしましたが問題無いようです。

書き出し時間は3倍位かかりますが、リアルタイムの3分の1程度で書き出せており、編集中に行った重たいエフェクトのレンダリングも

無駄になっていないので、といあえずの妥協点かなと思っています。安全第一！

こんな実験やってる場合じゃ無いんですけどね。。。

[wb-ks]

先日、2017.1アップデートしたところ、本件が直っているようですが、Adobeサポートさんの方では何か開発担当より情報はありますでしょうか？

現在、問題があったマシンでテストを重ねておりますが、今のところ問題無くスマートレンダリング状態で高速書き出し出来ております。

直っていませんでした！

メモリの使用状況によって、現象が出るようです。

高速ストレージ使用時は書き出し中にメモリを多く消費するようで、高速ストレージでスマートレンダリング書き出し中にAuditionで別作業をしていたら

残念ながら同一症状が頻発するムービーが書き出されてしまいました。

そこで、メモリの割り当てをあえて4G以下にして書き出しを行い、MACのアクティビティモニターでディスクのデータ転送量をモニタリングした結果

RAIDやSSD等の高速ストレージ間で読み込み・書き出しを実行中（素材もプレビューファイルも書き出し先もRAID）の時は数秒間、約500MB/秒で読み書きしては

数秒停止するという状態を繰り返して書き出しが終了する事がわかりました。

この状態で書き出されたムービーをPremiereで再生すると、タイミング的に書き込み中に転送が停止したあたりで赤いフレームが出ていると思われます。

そのため、単体のUSB HDD等で作業した場合、データ転送量が少ないぶん現象が滅多に出ないという考えに至りました。

いずれにせよ高負荷時は時間が余計にかかっても必ず正常に書き出せるか、途中で不具合がおきたらエラーメッセージを出して停止するべきです。

仕方が無いので、これまでのように全て再エンコードする設定で次のアップデートを待ちたいとおもいますが、

不安になったので、この設定でメモリを1GにしてAuditionをループ再生させながら同じシーケンスから書き出しテストを10時間位おこないましたが

まったく問題なく再生できております。

[Ckun]

心中お察しいたします。

Adobeさんからの音沙汰が無いようですと、特殊な事例なのかもしれません。

MacProはECC付きのメモリーとXEONなので信頼性は高いと思うのですが、放熱の問題やOSに未知の不具合が無いとも言えず、難しい検証になるように思います。

チャットで直接Adobeさんとやり取りをした方が、話が早く進むかもしれませんね。書き込み中に転送が止まって、そのタイミングにノイズが出るとなりますと、そのときのOSのエラーログに何か残っているかもしれません。OSやマシンに依存する問題ですと、Premiere側でエラーとして検知できない可能性もあるように思います。

本件と直接関係はありませんが、AMEの環境設定に「デコードエラーが検出された場合は現在のアイテムを停止する」という項目を見つけました。もしかすると以前のバージョンから付いていたのかもしれません。手元にデコードエラーになる素材が無いので確認はできませんが、この項目にチェックを入れておくことで、デコードエラーを無視して出力される危険は無くなるのではないかと想像しています。

[wb-ks]

Ckunさん、ありがとうございます。

Adobeさんとは前回電話で話しをしており、こちらのディスカッションの内容をふまえた上で開発に報告するという話でした。

今回の2017.1のアップデートで少し改善されたという感じです。

AMEのみを使用して夜中に20時間分くらいのバッチ書き出しを行った時は症状が出ませんでしたので。

本来、書き出し中に別作業をするべきではないのかもしれませんが、これで完全に直ったものと思って最後に負荷をかけた状態で試していて再発した次第です。

以前別件で他の方もおっしゃっていたのですが、2015.3以降メモリの制御がうまく出来ていない気がします。

テープに編集を使用時メモリの使用料が増え続け、開始後5分位でコマ落ちして止まってしまうという不具合があるのですが

こちらは全く改善されていない模様です。

この不具合に関しては別のマシン、別のIOデバイスでも同じように発生し、メモリの割り当てを8Gにすると安定して書き出しが

出来ており、2015.3以降変化がありません。

問題が起きているMacProとの相性の問題は確かに大きいかもしれません。

知り合いの話では都内の某ポスプロで同型MacProを新規導入して同じ問題が起きているらしいので。

AMEの「デコードエラーが検出された場合は現在のアイテムを停止する」は常に入れております。

[Ckun]

Adobeさんとは既にお電話でやりとりされていたのですね。失礼いたしました。

黒筒MacProはGPUレンダリング時の赤線ノイズで放熱の問題を指摘する意見を耳にしたことがありましたので、メモリーなどの熱暴走の可能性も、ごくごく僅かながら考えらるようにも思います。知り合いのプロダクションでは、扇風機で強風を当てて使用しているそうです。

もし余裕がありましたら、改めてApple Diagnosticsを何度か走らせてハードに問題がないことを確認した上で（Apple Hardware Testの時代は、複数回実行してたまにエラーになることがありました）、再度Adobeさんにコンタクトをとってみてはいかがでしょうか。こちらのフォーラムはAdobeさんからの返信がつきにくいようですので。

とはいえ、検証などに時間を割いてはお仕事に差し支えが出てしまうかもしれませんので、Adobeさんから解決の連絡が来るまでは、以前書かれてました強制再レンダリングでしのいだ方が健康的にも精神的にも良いかもしれないですね……

[wb-ks]

Ckunさん、ご返信ありがとうございます。

熱対策に関してはMacProは黒筒以前から弱いですね。

自宅等で常温で使用する場合、ファンの回転数を上げるアプリを使用していないとGPUが死んでしまった事が以前有りました。

問題の会社のMacPro2013はVTRやRAIDと一緒にマシンルームいれて、冬でも冷房20度で回しっぱなしなので

比較的環境は悪くないと思います。

Apple Diagnosticsは時間があるとき一度試してみたいとおもいます。

強制再レンダリングをご理解いただきありがとうございます。

とりあえず今回は確実な方法があるだけ精神的にはまだ楽です。