リンクをクリップボードにコピー
コピー完了
主にPremiere 2024で作業していますが、エンコードが遅すぎて困っています。
編集内容ですが、グリーンバックで収録した人物をRobuskeyで抜いて、
静止画2枚(jpeg、png)と動画(MediaEncoderでエンコードしたFHD H.265のmp4)を1トラック合成しています。
人物の素材は4K/4:2:2 10bit Long-Gop/H.264 のmovファイルです。
シーケンスは1920x1080のProRes422で、H.264に書き出ししています。
書き出し時に「プレビューを使用」にチェックを入れているにも関わらず、ほとんどの場合でプレビューファイルが参照されていないようです。
試しにちょうど1分の長さで書き出しのテストをしてみて、以下がその結果です。
レンダリング後「プレビュー使用」でPremiereから直接書き出し
レンダラーをGPUに設定 1分41秒(2025では1分47秒)
レンダラーをソフトウェアに設定 8秒(2025では5分41秒)
レンダリング後「プレビュー不使用」でPremiereから直接書き出し
レンダラーをGPUに設定 1分42秒
レンダラーをソフトウェアに設定 5分30秒
レンダリング後「プレビュー使用」でMEでエンコード
Pr、MEそれぞれのレンダラー設定の組み合わせを試したが、4種類全ての組み合わせで約2分
レンダリングしたプレビューファイルをシーケンスに乗せてPremiereから直接書き出し
レンダラーをGPUに設定 8秒
レンダラーをソフトウェアに設定 8秒
書き出しに時間がかかる時は必ず64%進んでから遅くなります。
何か解決策はありますでしょうか?
PCのスペックは以下の通りです。
windows11
Core i7 12700
RTX 3070
メモリ 96GB
GPUのドライバーは最新です。
リンクをクリップボードにコピー
コピー完了
こんにちは、ハナモゲラ さん
1番目の「レンダラーをソフトウェアに設定」が「1分41秒前後」になれば、1番目と2番目は整合性がとれているように思います。件名にある「プレビューファイルが無視され、エンコードが遅すぎる」ということは無いように思います。
3番目と4番目は分かりません。
◆1番目
レンダリング後「プレビュー使用」でPremiereから直接書き出し
レンダラーをGPUに設定 1分41秒(2025では1分47秒)
レンダラーをソフトウェアに設定 8秒1分41秒前後(2025では5分41秒)
◆2番目
レンダリング後「プレビュー不使用」でPremiereから直接書き出し
レンダラーをGPUに設定 1分42秒
レンダラーをソフトウェアに設定 5分30秒
私が思うに、私がPremiere Pro CS5バージョンを使用していた頃、高速処理に対応したGPU搭載機種は稀で、「プレビューを使用」は高速処理非対応GPU搭載機種やGPU非搭載機種では、書き出し時間を早くできるため、有効な手段でした。ただし映像が所々で振れる等の症状を呈したため試し書き出しでは使用しても良いが、本番では使用しないようにしていました。
現在では、高性能GPUが一般化し、ほとんどのGPU搭載機種では「プレビューを使用」を使用する必要性がなくなってきているように思います。
リンクをクリップボードにコピー
コピー完了
ご返信有難うございます。
レンダラーがGPUの場合に、プレビュー使用/不使用に関わらずエンコードに同じ時間がかかるので、
プレビューファイルが無視されているのではないでしょうか?
レンダラーをソフトウェアに変えるとエンコードが速くなるというのはネットで調べて見つけました。
リンクをクリップボードにコピー
コピー完了
こんばんは
>レンダラーがGPUの場合に、プレビュー使用/不使用に関わらずエンコードに同じ時間がかかるので、プレビューファイルが無視されているのではないでしょうか?
わたしが橙色で書いた通りならということでの推定です。
1番目は「プレビュー使用」、2番目はGPUでエンコードですので、時間的にはほぼ同じになると思います。
>レンダラーをソフトウェアに変えるとエンコードが速くなるというのはネットで調べて見つけました。
これはGPU高速処理のほうが速くなると思いますが。
「Mercry Playback Engine-GPU高速処理(CUDA)」が搭載されて間もない頃(2011年頃)、「ソフトウェア処理」と「GPU高速処理(CUDA)」の時間測定を行ったのですが、やはり「GPU高速処理(CUDA)」の威力をまざまざと見せつけられた記憶があります。
リンクをクリップボードにコピー
コピー完了
説明不足ですみません。
>レンダラーがGPUの場合に、プレビュー使用/不使用に関わらずエンコードに同じ時間がかかるので、プレビューファイルが無視されているのではないでしょうか?
これは双方で1分40秒かかっていることを指しています。
https://www.youtube.com/watch?v=O_o_D7GZhnM&t=170s
こちらの動画(1分20秒過ぎ)で紹介されていますが、レンダラーをソフトウェアにすると
何故かエンコードが速くなるのです。
先にGPUでレンダリングしていたプレビューも消えません。
1分のレンダリング済みシーケンスが実際に8秒でエンコード終了します。
リンクをクリップボードにコピー
コピー完了
バグ報告から返信がありました。
Premiereでは、コーデック変換を伴わず時間軸圧縮もしない場合のみプレビューファイルを使ったエンコードができるとの事です。
しかし、この説明は少し前にスマートレンダリングができるようになった!という発表の時の説明で目にしたもので、
バグにしろ2024でレンダラーを変更すれば速くエンコードできるなら、何らかの方法でプレビューファイルを参照したエンコードは可能だと思います。
せっかく作ったプレビューファイルをエンコード(変換含む)に使わせない理由が分かりませんね…。
リンクをクリップボードにコピー
コピー完了
私も詳細な経緯は把握しておりませんが、おっしゃる通り、ここ最近のバージョンではプレビューコーデックと書き出しのコーデックが同一の場合のみ、プレビューファイルを使用しての書き出しになるようです。私も実機で確認いたしました。
(私も以前は、XDCAM HD 50やProRes 422 HQにて、いわゆる「スマートレンダリング」のような使い方をしていたのですが、比較的パソコンの性能が良くなってからはプレビューファイルを書き出しには使用しない運用に変えたので、ここ数年のプレビューファイルを使用した書き出しの挙動には詳しくないのでございます……。)
公式の資料でこの件に関する記述が無いか探してみたのですが、2024年7月16日最終更新のこちらのドキュメントでも「プレビューを使用した書き出しの高速化」は書き出しとプレビューのコーデックが異なる場合にも機能するように書かれているので、残念ながら今のところ仕様変更があったのか否かなどわからないのが正直なところです。
>書き出しに時間がかかる時は必ず64%進んでから遅くなります。
>何か解決策はありますでしょうか?
こちらについては、原因を切り分けてゆかないと回避策は導き出せないのではないかなと思っております。
ちなみに、偶然の一致だとは思いますものの、「64%」というキーワードで過去にこのようなスレッドがございました。
解決済み: Re: エンコードが64%で止まってしまう - Adobe Community - 14827197
数分の短いシーケンスでも、数十分のシーケンスでも必ず64%で遅くなるのか否かですとか、いま作業されているシーケンスの真ん中よりやや後半あたりに、エフェクトなどで少し負荷が高い部分があるか否かということも、原因の切り分けに役立つ情報になるのではないかなと思います。
リンクをクリップボードにコピー
コピー完了
検証有難うございます。
同一コーデックの場合のみ「プレビューファイルを使用する」が効果を発揮するという意見は私も目にしました。
ただプレビューファイル作成後にレンダラーを一旦ソフトウェアに変えて、
Premiereから直接書き出す時のみコーデックの変換を伴うエンコードが速くなる(GPU100秒→CPU8秒)という現象が不思議なのです。
シーケンスと同じProRes422で書き出したムービー(=プレビューファイル)を再度同一設定のシーケンスに放り込んでからエンコードする時と同じ速さです。
これはレンダラーがソフトウェアの時のみプレビューファイルを正しく参照できていると考えられないでしょうか?
64%でエンコードが遅くなるのは、尺の長さやエフェクトに関わらず
レンダラーがGPUの時は必ず発生します。
ちなみに2025ではレンダラーをソフトウェアにしてもエンコードが遅く、
シーケンス設定と同じムービーを一旦「書き出し」て、
それを同一設定のシーケンスに放り込んでからエンコードすると速く終わります。
約19分のシーケンスで、レンダリング後の「書き出し」 に2分、
H.264へのエンコードに2分30秒前後という感じです。
リンクをクリップボードにコピー
コピー完了
ご案内いただいたスレッドでCkunさまがアップしてくださったプロジェクトをチェックしました。
3分のシーケンスで、GPUレンダー・H.264への直接エンコードでも16秒ほどで終わります。
※シーケンス設定は上記の自分のシーケンスと同じに変更しました。
このプロジェクトには動画素材が含まれていないので、自分のプロジェクトでエンコードが遅くなるのは素材に問題がある可能性もありますね。
リンクをクリップボードにコピー
コピー完了
冒頭に提示したシーケンスを以下の条件で再度チェックしたところ、気づいたことがあります。
レンダリング後「プレビュー使用」でPremiereから直接書き出し
レンダラーをGPUに設定 1分41秒
レンダラーをソフトウェアに設定 8秒
まず、プレビューファイル作成の為のレンダリングに約1分30秒かかり、
CPUレンダラーでのエンコードにおける8秒を足すと、GPUレンダラーでエンコードした場合と同じような時間になります。
GPUレンダラーでエンコードした場合は、プレビューファイルを作っていても
レンダリングからやり直してしまうので1分40秒かかっていると思われます。
リンクをクリップボードにコピー
コピー完了
おっしゃる通り、整合性のない挙動だと私も思います。
私も一ユーザーに過ぎませんので、今目の前で起きている以上のこと(Premiere Pro内部の設計や機能の実装方法など)は、残念ながらわかりません。
ただ、この件に限らず、「おかしいな」と思う挙動はございまして、100%全てが完璧に動作しているとは言い難い面もあるのは否めないところでございます。
(アドビのエンジニアさんが、日々頑張ってくれていると信じております……。)
現状では、レンダラーが「ソフトウェア処理」の場合には期待通りに動作し、レンダラーがGPU高速処理の場合に期待通りの動作をしないわけですが、それが意図的な仕様変更で各ドキュメントの更新が遅れているだけなのか、バグなのかは、アドビのスタッフさんに聞いてみないとわからないところでございます。
一方で、
>レンダラーをソフトウェアにすると
>何故かエンコードが速くなるのです。
>先にGPUでレンダリングしていたプレビューも消えません。
こちらの「レンダラーを変更しているにも関わらずレンダリング済みのプレビューファイルが残ってしまっている」ことも、ある意味問題と言えると思います。
釈迦に説法になってしまうかもしれませんが、「ソフトウェアレンダリング」と「GPU高速レンダリング」は、単純に処理速度が異なるだけではなく、リサイズのアルゴリズムが異なり、(設定によりますが)処理のビット深度が異なることもございます。
そのため、レンダラーが異なるパートが同一シーケンス内に混在することを防ぐ意味でも、レンダラーを変更した際にはレンダリングファイルが破棄されるのが自然な動作と言えるのではないかなと思います。(これはあくまでも私個人の考えなので、現状の挙動が不具合なのか意図されたものなのかは、わかりません。)
もっとも、ソフトウェアレンダラーは過去の遺物(GPUレンダリングができない場合のフォールバックでもありますが)なので、今後進展することはほぼ無いのかなとは思います。
いずれにしましても、「わからない」と連呼した返信をしても意味がないので回避策を考える必要があると思うのですが、私は過去に他社製のソフト(Final Cut Pro の7以下の頃)を使用していた時から、「レンダリングの代わりにビデオの書き出しを使用し、書き出されたファイルを一番上のトラックに貼り付ける」という方法を好んで使用していました。
音声編集でいうところの「バウンス」に近い考え方かなと思います。
Premiere Proの場合、書き出し時に自動的にプロジェクトに読み込む設定にチェックを入れておくと、若干ですが読み込む手間が省けるかと思います。
理屈としては、すでにおやりになられている、
>レンダリングしたプレビューファイルをシーケンスに乗せてPremiereから直接書き出し
この考え方と同じものですね。
リンクをクリップボードにコピー
コピー完了
有難うございます。
いつからこうなったのか分かりませんが、対症療法でやり過ごすしかないですね。
Adobeには新しい機能を増やすよりもこういうバグ?を潰したり、基本的な動作を軽くするということに
真剣に取り組んで欲しいです。
ちなみにM3搭載のMacBookAirでは、1分のレンダリング済みのProRes422シーケンスを
H.264にエンコードするのに直接書き出しで47秒、ME経由だと25秒です(笑)
リンクをクリップボードにコピー
コピー完了
開発リソースには限りがあるからだと思うのですが、軽微なバグや機能リクエストに関しては、リクエストの多いものから対応するといった流れになっているようです。
今ページ右上もしくは下部に表示される「★バグの報告はこちらから。Pr英語フォーラム▶ Bugs タブ ▶ 右上"post to community"投稿作成。日本語でOKです。」という部分のリンクからご報告いただけますと、アドビのスタッフの方から何かしらのリアクションがあると思います。
致命的な不具合ではなかったり、その問題でお困りの方が多くはない場合には、解決まで時間がかかることが多い印象を受けます。
いまPremiere Proはカラーマネージメントの機能が充実しつつある状況なので、書き出し時にフォーマットに合わせて色域変換をする使い方(シーケンスは広いカラースペースのLog空間にするなど)をふまえると、プレビューファイルを書き出し時に使用する機能にはあまり目を向けられないのかなーと、個人的には思っていたりもします(もちろん、それが放置してもよいという理由にはならないとは思います)。
リンクをクリップボードにコピー
コピー完了
有難うございます。
バグ報告に投稿しました。
リンクをクリップボードにコピー
コピー完了
バグ報告から返信がありました。
Premiereでは、コーデック変換を伴わず時間軸圧縮もしない場合のみプレビューファイルを使ったエンコードができるとの事です。
しかし、この説明は少し前にスマートレンダリングができるようになった!という発表の時の説明で目にしたもので、
バグにしろ2024でレンダラーを変更すれば速くエンコードできるなら、何らかの方法でプレビューファイルを参照したエンコードは可能だと思います。
せっかく作ったプレビューファイルをエンコード(変換含む)に使わせない理由が分かりませんね…。
リンクをクリップボードにコピー
コピー完了
その後の経過のご返信、ありがとうございました。
ちなみに、バグ報告のスレッドはこちらでしょうか?
GPU処理でのエンコードが遅い - Adobe Community - 15294658
もしかすると、アドビの社員さんはご報告いただいた内容の本質を理解されていないかもしれないですね。
(私もたまに日本語でバグ報告するのですが、なかなか細かいニュアンスが伝わらず、少々的外れな返信が返ってくることも……。)
>バグにしろ2024でレンダラーを変更すれば速くエンコードできるなら、何らかの方法でプレビューファイルを参照したエンコードは可能だと思います。
はい、おっしゃる通り、いつ頃のバージョンだったかは忘れましたが、過去にはプレビューファイルを使用した書き出しができたはずです。
それが悪い方向に作用して「低画質のプレビューコーデックでレンダリングしたファイルを使用することで、最終書き出しの画質が悪くなってしまった」というトラブルもあったように記憶しております。
(私自身は、Final Cut Pro 7の終焉と共にPremiere Proに移行したので、それより前の事情にはあまり詳しくないです。)
私の曖昧な記憶に頼るまでもなく、アドビの公式のページ内にその記述(ベストプラクティス:書き出しの高速化 :プレビューコーデックを「メザニン(中間)コーデックに設定できる云々」)がありますので、この記事の公開より後に「何らかの理由で意図的にこの機能を無くした(しかしバグでソフトウェアレンダリング時に誤って機能が復活してしまう)」のか、「プログラムのミスなどでGPUレンダラー使用時にこの機能が強制的にOFFになってしまっている」のかの、どちらかなのかなと思います。
(意図的な仕様変更の場合、非圧縮444ではない限りプレビューファイルを用いて異なるコーデックで書き出すと劣化が生じることや、カラーマネージメントの面で不整合が出る可能性があることなどが、その理由かもしれないと勝手に推測しています。)
いずれにしましても、すぐに解決される可能性は低いのではないかと思いますので、レンダリングの代わりに書き出しをして、一番上のトラックに乗せてやるといった方法でしのぐしかないのではないかなと、個人的には思います。
(ソフトウェアレンダリングにする方法ですと、万が一どこかほんの一部だけレンダリングファイルが外れていたりすると、そこがソフトウェアレンダリングされて画質が落ちる可能性もありますし……。)
リンクをクリップボードにコピー
コピー完了
ご返信有難うございます。
スレッドはそれです。
私もFinal Cut Pro 7から流れついた者で、プレビューファイルを用いたエンコードは当然できるものと思っておりました。
私の場合はせいぜいH.264もしくはH.265での納品がほとんどですので、シーケンス設定をProRes422にして「最大ビット数」をonにしておけば十分だと考えていました。
最近もレンダラーをGPU限定にしたらユーザーから反発をくらって、オプションでCPUも選べる用になったという件がありましたが、ユーザーに選択肢は残して欲しいですね。
「プレビューを使用」に関してもoffにすれば意図しない画質低下は完全に防げる訳ですので。
新しいアドビコミュニティで、さらに多くのインスピレーション、イベント、リソースを見つけましょう
今すぐ検索