PiTiVi Video EditorについてのEdward Herveyへのインタビュー

これは、4番目のオープンソースマルチメディアインタビューです。 これまでの会話は、 Jokosher 、 Totem、 Empathyプロジェクトに関係していました（ 翻訳 ）。 PiTiVIプロジェクトに付随してエドワード・ハービーと話をします。 エドワードは、ビデオエディタの現在の状態と将来の計画について話します。



それでは、まず、あなた自身について少し教えてください。あなたが参加しているプロジェクトを開いてください。



私の名前はエドワード・ハービー、私はバルセロナに住んでいるフランス人、スコットランド人の半分で、 Collabora Multimediaの創設者の一人です。 1995年頃からLinuxとフリーソフトウェアを使用しています。 しかし、私は2003年にPiTiViの作業を開始するのに十分なプログラミング知識をようやく得たときに貢献し始めました。 ここ数年、私はGStreamerマルチメディアフレームワークに取り組み、ビデオ編集を適切なレベルに引き上げています。 また、GStreamer用のpythonバインダー、GNonLin（PiTiViの主な依存関係、ノンリニア編集を担当）、およびGStreamer用のFFMpegプラグインも長年にわたって提供しています。



iMovie、Avid、Final Cut Proなどの主要なビデオ編集アプリを背景にPiTiVIの目標を説明してください。



PiTiViにはさまざまな目標がありますが、基本的な目標-制限なしでビデオエディタを作成したいという要望に注意します（使用やサポートに非常に特定の制限があるアナログとは異なります）。 フォーマット、デバイス、フィルターなどの制限を取り除くために、GStreamerフレームワークを通じてそれらをサポートできます。 他のすべてのエディターはコードに密接に結びついていますが、特許ライブラリーに拘束されることなく、無料のエディターの名前を誇りに思っています！ これは、企業が特定のフォーマット/コーデック/デバイス用に独自のGStreamerプラグインを作成している場合... PiTiViで自由に使用できることを意味します。 この障壁は、開発モデルを選択することで克服されます。



モノリシックなビデオエディターを取得したくないため、PiTiViをPythonで書き直し、プロジェクトをモジュール化することにしました。 ユーザーインターフェイスはエンジンに関連付けられていません。実際、エンジンは個別に使用できます。 年代順テープをさまざまな方法で実装できるように設計されています。知識とアクセントの付け方にさらに依存し、アクセントは制作プロセスのアプリケーションに依存します。



PiTiViの最終目標は、制限なしに基本的な編集ツールを提供することです。 残念ながら、これは多くの努力の価値があります。ハックの後にハックを追加するのではなく、すべてのエラー、問題、制限が適切なレベルで修正されることを確認する必要があります。 そして時間がかかります...



PiTiVIはPythonで書かれています。 多くの人がこれを聞いたときに最初に尋ねる質問は、「Pythonの使用がマルチメディアアプリケーション、特にビデオエディターのようなリソースを大量に消費するアプリケーションのパフォーマンスにどのように影響するか」



すべてがシンプルです:)ビデオを編集するときにCPUに最大の負荷をかけるのは何ですか？ そうです、マルチメディア処理（表示、エフェクトの適用、レンダリングなど）。 これはすべて、GStreamerとそのプラグイン（Cで記述され、個別のストリームで動作し、Pythonバインダーを介してPiTiViで使用されます）の助けを借りて排他的に行われます。 そして、プロセッサの残りの処理能力をどのようにロードしていますか？ ユーザーインターフェース GTK + / X / Cairoはこれを行っています（Cで記述され、Pythonバインダーを介してPiTiViで使用されます）。



したがって、残っているのは、すべてを一緒に接続し、ノンリニアビデオ編集システム（NLE）に固有の概念を引き付けるロジックです。 コードをできる限り高速かつ柔軟に作成したいので、Pythonのような言語は非常に便利です。 さらに、Pythonで書くことは喜びです:)



不思議なことに、興味深い事実を紹介します。PiTiViでプレイするとき、Pythonで実装されるのは、現在の位置を表示するコードだけです。 レンダリング時も同じです。 それ以外はすべて、GStreamer、そのプラグイン、GTK +によって完全に処理されます。



MXFコンテナ形式をサポートするために、GStreamerで多くの作業が行われました。 ほとんどの人は、おそらくこのような形式を聞いたことがないでしょう。どのような価値がありますか？



コンピューター編集（ノンリニア編集とも呼ばれます）の出現以来、各プログラムは異なるフォーマット/コーデックを使用して機能しています。 カメラ、VCR、キャプチャデバイスなど、プロとアマチュアが使用したものも異なりました。 これに、ほとんどの形式が文書化されていないという事実を追加してください。 ソフトウェア、カメラ、出力でさまざまなフォーマットを取得します...完全な混乱。



SMPTE （Society of Film and Television Engineers）の代表者であるプロ市場の主要なプレーヤーの一部は、共同で作業することを決定し、完全に文書化され、メタデータの保存を可能にし、カメラに直接記録され、ストリーミングとクイック検索を可能にする新しいコンテナー形式の仕様を書きました... AAF （高度な開発フォーマット）と同じ構造要素を使用します。AAFは、Avid、Final Cut Pro、その他の多くのノンリニアビデオ編集システムで使用されています。



GStreamerにMXFサポートが追加されたことにより、PiTiViでプロのNLEと同じフォーマットを使用できます！ 一般的な形式で直接作業できることは、既存の生産プロセスでPiTiViを使用できる主な要因です。



PiTiVIはどのマルチメディアフォーマットをサポートしていますか？



システムにインストールされたGStreamerプラグインを介して利用可能なすべて、および迅速なビデオ編集、正確な検索、Iフレームコーデックなどのためのいくつかの形式



現在、PiTiVIはどの段階にあり、将来の計画は何ですか？



過去6か月間、昨年の夏に行った分析に基づいて、PiTiViコードの深いリファクタリングを行い、過去5年間の応答をまとめました。 最も簡単に実装できる機能を追加するだけでなく、マルチレイヤー編集、スケッチ、トリミング、リップル/ロールモード、一般的なファイル形式のサポートなどが既に用意されています。



5月に新しいpitiviの最初のプレリリースを行う予定です。 徐々に、新しい機能がインターフェイスに追加されます。たとえば、トランジション、エフェクト、オーバーレイ、スリップ/スライドの編集、および他のエディターからのプロジェクトのインポートを可能にする多数の形式のサポートなどです。



用語に慣れていない人にとって、レイヤード編集、スケッチ、トリミング、リップル/ロールモードとはどういう意味ですか？



マルチレイヤー編集：時間だけでなく、複数の並行レイヤーにビデオをソートする機能。

スケッチ：タイムラインスケールで使用されるソースごとに結果の画像が表示されます。これにより、検索を必要とせずに時系列フィードでナビゲートしやすくなります。

切り抜き：ソースの開始または終了の位置を変更します。

リップル編集：パーツの1つを縮小または拡大し、残りのデータは変更されたクリップの新しいサイズに合わせて調整します。

ロール編集：リップルと同じですが、クリップのグループの合計時間が変わらないことを除きます。



あなた以外のPiTiVIプロジェクトに参加しているのは誰ですか？



私以外の2人の主な開発者はBrandon Lewisで 、彼はGSoC 2007での作業を開始し、ユーザーインターフェイスで忙しくしています。 Alessandro Decina（Alessandro Decina）は10月に私たちに加わり、PiTiViの低レベルの部分で私を助け、GStreamerを改善しました。 両方とも、昨年秋からCollabora Multimediaで働いており、常にPiTiViに取り組んでいます。 Collabora MultimediaのPiTiViに非常に多くのリソースを集めるビジネス上の理由を考える人への説明：まず、コンテンツ作成業界の顧客にコンサルティングサービスを提供し、PiTiVIを使用して生産プロセスの特定のタスクを実行したい、作成したPiTiViインフラストラクチャを使用して自動ビデオ操作をセットアップするクライアントがいます。 たとえば、自動トリミング、スケーリング、およびトランスコーディング。



GStreamerの今後の変更はPiTiVIにどのように影響しますか？



現在のGStreamerコアとプラグインにはかなり機能する機能があるという事実にもかかわらず、編集インターフェイスを改善するために多くの機能の改善に取り組んでいます。



非常に必要な機能の1つは、より広範なプラグインを使用したGstIndexサポートの実装です。 これにより、インポート中に不便なファイルをスキャンして編集し、これらのファイル内をすばやく移動できるインデックスを作成できます。 これにより、PiTiViなどのアプリケーションは、ファイル形式、キーフレームの場所に関する詳細情報を取得できるようになります。これにより、スキップしたほうが収益性の高いセクションとロスレスクリッピングを行う場所がわかります。



ますます多くのライブラリをプラグインとして移植するために、GStreamerで無限の作業を行う必要があります。 GStreamerはコーデックライブラリであると誤解されることがよくありますが、これは完全に間違っています。GStreamerは、アプリケーション開発者が処理を心配せず、ライブラリ開発者がそれらを使用するアプリケーションを心配しないフレームワークです。 gavlなどのプラグインや、大多数のすばらしいAviSynthフィルター（Google Summer of Codeの一環としてこの夏に完成予定）をGStreamerに移植する予定です。 もちろん、これはすべてPiTiViのユーザーエクスペリエンスを向上させます。



さらに、GStreamerコアとさまざまなプラグインのメモリ消費とCPU時間を削減します。 VDPAUテクノロジー、VA-API、gst-plugins-glプラグインを備えたビデオカードなど、ハードウェアデバイスのより効率的な使用を検討しています。 これにより、GStreamerアプリケーションは処理をハードウェアデバイスに向けることができ、ユニバーサル処理のためのプロセッサー時間が長くなります。



JokosherとPiTiVIは、GStreamerを使用するマルチメディアアプリケーションであり、Pythonで記述されています。 自然な質問は、これらのプロジェクトが協力しているかということです。



残念ながら、私たちが望むほどアクティブではありません。 すべての面（GStreamer、Pythonバインダー、GNonLinプラグイン）で互いに助け合いますが、ユーザーインターフェイスとメインロジックに関しては、コードを使用するためのさまざまなオプションとさまざまなコードベースがあります。 緊密に統合することは素晴らしいことです。これにより、Jokosherを使用してビデオクリップのオーディオ部分を編集し、PiTiViがビデオを残すことができます。



Linux / Unixシステム用のビデオエディタの作成中に発生した主な技術的問題は何ですか？ Linuxインフラストラクチャは、そのようなアプリケーションをホストする準備ができていますか？ また、Linux / Unixのマルチメディアの一般的な状況についてどう思いますか？



過去10年間で、オープンソースのマルチメディアは*長く*進歩しました。 覚えていない人のために...デジタルカメラからビデオをキャプチャする唯一の方法であるフォーマットに応じて異なるプレーヤーを使用することを余儀なくされました。 しかし問題は、誰もが自分のコーナーで自分のソフトウェアを作ることです。 Linuxのさまざまなマルチメディアアプリケーション、ライブラリ、およびデバイスサポート間の完全な一貫性の欠如。これが、私たちが適切なマルチメディアプラットフォームにならなかった理由です。 他のプラットフォーム（Win / Mac）とは異なり、独自のライブラリを書き換える必要はなく、既存のライブラリを再利用できます...なぜこれが起こらないのですか？ GStreamerは、すべての人を集めてこれらの問題のほとんどを解決しようとしていますが、不明な理由で一部の開発者からのキックを受け取ります。 当日、この問題を解決します...組み込みデバイスやサーバーで行ったように、デスクトッププラットフォームで支配的になります。



他にどのようなマルチメディアアプリケーションを使用していますか？



Totem 、 Rhythmbox 、 Audacity （ああ、彼はGStreamerを使用していません）。 時々、WINEを介してAviSynth / VirtualDub （Win32アプリケーション）が使用されますが、AviSynthフィルターをGStreamerに転送するように設計されたGSoCプロジェクトのおかげで、これは変更される場合があります。



さて、このインタビューに時間を割いてくれたエドワード、ありがとう。



PiTiViプロジェクトの詳細については、 pitivi.orgまたはirc.freenode.netの#pitiviチャンネルにアクセスしてください 。



インタビューはクリスチャンFKシャラーが作成しました。

_____

翻訳の準備に協力してくれたShutteR77とilembitovに感謝します。