問題タブ [libx265]

x264 と x265 のエンコーダーlosslessとmediumプリセットを比較しています。以下のパフォーマンス結果を見てとても驚いています。

それは私に2つの質問を提起します

1. ロスレス エンコーディングは、ロッシー エンコーディングよりも 1 秒あたりのフレーム数が少ないのはなぜですか? （処理が少ないはずだと思いました）

2. x265 ロスレス出力が x264 ロスレス出力よりもはるかに大きいのはなぜですか? これは実装の影響ですか、それとも HEVC 標準に関連していますか?

ffmpeg を使用して、x265 エンコーダーを使用して HEVC/mkv ビデオの 16 ビット グレースケール イメージを損失なく変換したいと考えています。私はmonochrome12プロファイルを使用しています。私の最初のステップは、画像を yuv 形式に変換することです。

そして、ロスレスで.mkvファイルとして変換しようとします:

しかし、私は得る

lossless=1 を書かないときはすべて正しいのですが、この方法ではロスレスのビデオを作ることができません。

ご協力ありがとうございました。

FFMPEG のモーション検出部分を変更しようとしています。私がやりたいことは、マクロブロックがフレームの右端に当たるたびに、ブロックが接続されているかのようにブロックを左端に移動する必要があるように、検索スペースを拡張することです (私の例のビデオでは、右端は実際には左端の続きです)。FFMPEGソースコード、x265、またはx264内で正確にどこを変更できるか教えてもらえますか?

ここからH265を例に取りました。motion.cpp以下のように、可能なブロックサイズを適切に指定するファイルがあります。しかし、フレームを横断する特定のループが見つかりません。助けていただければ幸いです。

アップデート：

これを (x265 で) 行う 1 つの方法は、エッジ拡張領域 (既にコード内の にあります) を変更し、frameFilter.cppそれを右端に対して行い、ブロックを左端のピクセルで塗りつぶすことです。ここでコードを特定しました。誰かが右から左への拡張のためにこの機能を追加するのを手伝ってくれますか?

H.265 モーション補正と検索 (HEVC-ここからの libx265 実装: https://bitbucket.org/multicoreware/x265/downloads ) で遊んでみます。エッジ拡張検索を少し拡張し、サンプル ビデオが円柱のように見えるように (右端が左端に接続されているように)、左端のピクセルでマクロ ブロックを埋める必要があります。

私がする必要があるのは基本的にこれです：

これを行う 1 つの方法は、エッジ拡張領域 (既にコード内の にありますframeFilter.cpp) を変更し、ブロックの右端と左端のピクセルで外れた部分を塗りつぶすことです。ここで、明らかにその原因となっているコードを特定しました。誰かがこの機能の実装を手伝ってくれますか?

Xcode4.6.3 内で llvm-gcc-4.2 を使用して「x265」ソースをコンパイルすると、奇妙なエラーが報告されました。ただし、x265::MotionReference のクラス宣言は、reference.h で完了しています。

親クラスはヘッダーファイル「lowres.h」で定義されています。

誰も理由を知っていますか?手がかりをいただければ幸いです!事前に感謝します!

h265 の法外なライセンス費用のために、Google と Alliance for Open Media が独自のコーデック (vp9/av1) を作成していることを読みましたが、gpl v2 でライセンスされているオープン ソースの x265 エンコーダーがあることを知りました。無料で使えますよね？

では、なぜ Google と Alliance for Open Media は独自のコーデックを作成しているのでしょうか?

私は現在、最新の画像およびビデオ圧縮コーデックを拡張してパフォーマンスを向上させることに取り組んでいる大学院生です。現在、 BPG (Better Portable Graphics) と x265 (HEVC/H.265 実装) の修正に取り組んでいます。

私の現在のアプローチでは、追加のイントラ予測モードを追加して、上の CTU (コーディング ツリー ユニット) の 1 ピクセル行と CTU の左の 1 ピクセル列よりも多くの情報を利用できます。

私は自分のアプローチを実装し、イントラ予測モードを「35」と名付けました (BPG と hevc は 0 ～ 34 のモードを使用します)。現在のアプローチでは、イントラ予測モードを使用するたびに、2 つの追加の数値 (12 ビット) を格納する必要があります。これらの 2 つの数値をビットストリームに埋め込む (エンコード) ときと、ビットストリームから取得する (デコードする) ときに問題に直面しています。

BPG で提供される x265 パッケージのentropy.cppの関数codeIntraDirLumaAngを変更して、新しいイントラ予測モード 35 に遭遇したときに 2 つの追加の数値を書き込むようにしました。

私の一連の質問は次のとおりです。

1) より多くの予測モードがあり、さらに増加すると予想される場合、次のコード行を変更する必要があります。

することが

2) デコーダーを実行すると、最初にモード 35 を格納する必要がある場所のインスタンスに遭遇しました。それを読み取ることができず、代わりにモード 26 を読み取ります。これは、hevc での Intra-Luma Pred-Dir の導出手順が原因だと思いますか? （正しく読み取れるように、新しいイントラ予測モードをビットストリームに正しく埋め込む方法についての入力はありますか）？

3) エンコードする 2 つの追加の数値の CABAC 状態で何かを行う必要がありますか? この新しい種類の情報を処理するための追加のコンテキストを作成しました。さらに定義した NUM_STATES_CTX 変数の値を設定する方法と、これら 2 つの数値を最適にエンコードするために CABAC を使用する方法についてのポインタをいただければ幸いです。

videolan が開発したこれら 2 つのコーデック ライブラリについて 1 つ質問があります。

x265(libx265) はデコーダーを実装していますか? x264(libx264)についても同じ質問です。

回答ありがとうございます。