☰

VLCは600MBのRAMを占有します。なぜ？

tag-icon • tag-icon ram vlc
VLCは600MBのRAMを占有します。なぜ？

2つのインスタンスが実行中ですvlc。一人は遊んでいます。そのうちの1つが一時停止しました（ほとんどが交換されました）。

top - 14:25:01 up 23 days, 19:19, 69 users,  load average: 2.36, 2.61, 4.19
Tasks: 905 total,   3 running, 894 sleeping,   2 stopped,   6 zombie
%Cpu(s): 11.9 us,  6.5 sy,  0.1 ni, 81.0 id,  0.4 wa,  0.0 hi,  0.0 si,  0.0 st
GiB Mem :     31.2 total,      0.8 free,     27.4 used,      2.9 buff/cache
GiB Swap:    158.3 total,     82.4 free,     75.8 used.      1.5 avail Mem 

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND            
 420221 tange     20   0 4066448 601160  28444 S  30.3   1.8   8:55.51 vlc <-- playing
1329863 tange     20   0 2640256 131980  42300 S   0.7   0.4  11:47.28 vlc <-- paused

ビデオの解像度は1280x720px 30fpsで、強制的にスワップアウトすると約100MBしか再スワップされません。

なぜそんなに多くのメモリを占めるのですか？ （600MBの再生はとんでもないようです。）この使用量を減らすにはどうすればよいですか？

編集する：

もっと調べました。

以下の数字はキロバイト単位で、「time -v」を使用して測定されます。彼らは「トップ」に同意した。

これらは常駐し、VLCを閉じると最大値に達します（つまり、より低いレベルを見つけるために一時的に急増しません）。

「再生」とは、動画全体を再生することを意味します。 「一時停止」とは、最初の数秒間再生した後、メモリ使用量が安定するまで一時停止することを意味します。

以下は、「リスト内の2087の大きなビデオで1280×720を再生する」のグラフです（ps aux毎秒600秒で測定）。

リストにRSS / VSize / CPU 2087があります。

以下は、「リストにゼロの大きなビデオを持つ1280×720再生」のグラフです（ps aux100秒あたりの秒単位で測定）。

リストにRSS / VSize / CPU 0があります。

これは、「リストのゼロ」の使用がやや過大評価されたことを意味します。 RSSは開始直後にピークに達し、15秒後にわずかに低下します。

VSizeは常にRSSより2.3GB大きい。

リストに5400ビデオを含む640×360再生：最大常駐セットサイズ（キロバイト）：1096232

リストに5400ビデオを含む640 x 360一時停止：最大常駐セットサイズ（キロバイト）：1101840

リストに0つのビデオを含む640 x 360再生：最大常駐セットサイズ（キロバイト）：333228

一時停止640x360、リストにあるビデオ0：最大常駐セットサイズ（キロバイト）：303792

リストに2087の大きなビデオを持つ1280×720再生：最大常駐セットサイズ（キロバイト）：1273936

一時停止1280x720、リストの大規模ビデオ2087：最大常駐セットサイズ（キロバイト）：1190252

リストに0つのビデオを含む1280×720再生：最大常駐セットサイズ（キロバイト）：185204

一時停止 1280x720, リストに動画 0 個: 最大常駐セットサイズ (キロバイト): 185352

これは、プレイリストがRSSに大きな影響を与える一方、ビデオ解像度はそうではないことを示しているようです。

理由は不明です。

VLC は各ビデオの長さを明確にキャッシュします。ビデオの長さはリストにゆっくりと表示され、これは図に示すようにメモリがゆっくり増加することを示しています。しかし、長さはほんの数バイトです。 VLCが何をしても、リスト内の各ビデオは150kb〜500kbの常駐RAMを占めています。

1280x720を再生するには、200MB RSSが合理的であると考えていましたが、800MB RSSを追加しないと、プレイリストはRAMに残ります。

VLCにRAMにキャッシュせずにリストを維持するように要求できますか？

ベストアンサー1

これは比較的妥当に見えます。つまり、私たちがソフトウェアデコードを実行している（つまり、ハードウェアでデコードするために前処理されたビデオデータをGPUバッファに送信するのではなく）、フルHDを扱っていてMPEG4時代を扱っていると仮定します。コーデックデバイス。

その後、次のフレームが十分に離れて送信されるように簡単にレンダリングされる（つまり、グラフィックカードに転送できる（またはここで出力として機能するすべての項目によって処理される）静的画像形式に分割された）いくつかのフレームを維持する必要があります。再生時に遅延がないはずです。特に輻輳したCPUでソフトウェアデコードが発生する場合は、あらかじめ多くのフレームを計算してRAMに書き込んでから、OSがスレッドまたはそれ以前に時間を再スケジュールすることを願っています。現在表示されている画像を変更して画面を更新するハードウェアユニットが完成しました。

これで、24ビット深さのフルHDフレーム（これが使用されているテクスチャ形式であると仮定していますが、そうである可能性が高い）は約6MBです。これが約1/4秒のバッファにすぎないことを考慮すると、転送/ビットブロックのために約100MBの画像を準備することは無駄のように聞こえません。

しかし、そのフレームをレンダリングするには、多くの小さな基本コンテンツで構成されたビデオをデコードする必要があります（MPEG-2やその他のコンテンツは、一部の係数をあまり量子化できないいくつかの変換で小さな画像チャンクを処理するという点で、JPEGと変わらないと思います） （これは圧縮されています）だけでなく、相対モーションマップ（1/4ピクセル解像度でもモーション補償）や遠いフレーム間の補間など、非常に長距離のアイテムも含まれます。 MPEG-4 AVC（H.264）は最大16個の参照フレームを使用します。新しいフレームを得るために結合します。
これは、個々のフレームを異なる方法で使用する必要があるため、依然として必要な参照フレームよりも大きい中間結果を生成できることを意味します。

今、私は600MB未満のバッファを使用してデコーダを書くことが可能でなければならないことに同意しますが、（デコーダへの実際の洞察なしに）他のフレームで再利用できる中間結果があるかもしれません。 、ほとんどの場合、メモリプールに戻るか、後で上書きします。これはデコードメモリを「膨らませる」が、パフォーマンスには良い。

おすすめ記事