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秒で測定）。
以下は、「リストにゼロの大きなビデオを持つ1280×720再生」のグラフです（ps aux100秒あたりの秒単位で測定）。
これは、「リストのゼロ」の使用がやや過大評価されたことを意味します。 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未満のバッファを使用してデコーダを書くことが可能でなければならないことに同意しますが、（デコーダへの実際の洞察なしに）他のフレームで再利用できる中間結果があるかもしれません。 、ほとんどの場合、メモリプールに戻るか、後で上書きします。これはデコードメモリを「膨らませる」が、パフォーマンスには良い。
答え2
犯人を見つけました。
ツール > 環境設定 > ディスプレイ設定 > 全体 > プレイリスト > 自動でアイテムを準備する
このオプションをオンにすると、VLC はプレイリストの各ファイルを読み取り、ビデオの長さを検索します。明らかにそれはまた多くを読みます。
無効にすると問題がなくなり（VLCは200 MB未満に保たれます）、再度有効にすると問題が再び表示されました。
私にとって、これはVLCのバグのようです。なぜビデオの長さを保存することは、全長の数メガバイト以上を占めるのですか？
答え3
私はUbuntu 20.04で何も再生せずにVLCインスタンスを起動し、メモリにpmap PIDマップされた内容を確認するために実行しました。いくつかの興味深い抜粋：
000055ac2ba89000 1036K rw--- [ anon ]
00007f616c000000 132K rw--- [ anon ]
00007f616c021000 65404K ----- [ anon ]
00007f6170000000 132K rw--- [ anon ]
00007f6170021000 65404K ----- [ anon ]
00007f6174000000 132K rw--- [ anon ]
00007f6174021000 65404K ----- [ anon ]
.
.
.
00007f617affd000 4K rw--- [ anon ]
00007f617affe000 4K ----- [ anon ]
00007f617afff000 8192K rw--- [ anon ]
00007f617b7ff000 4K ----- [ anon ]
00007f617b800000 8192K rw--- [ anon ]
00007f617c000000 132K rw--- [ anon ]
00007f617c021000 65404K ----- [ anon ]
00007f6180000000 132K rw--- [ anon ]
00007f6180021000 65404K ----- [ anon ]
00007f6184000000 8160K rw--- [ anon ]
00007f61847f8000 57376K ----- [ anon ]
00007f6188000000 132K rw--- [ anon ]
00007f6188021000 65404K ----- [ anon ]
.
.
.
00007f6190000000 65536K rw-s- memfd:pulseaudio (deleted)
00007f6194000000 65536K rw-s- memfd:pulseaudio (deleted)
00007f6198000000 65536K rw-s- memfd:pulseaudio (deleted)
00007f619c000000 65536K rw-s- memfd:pulseaudio (deleted)
.
.
.
total 983604K
これは単にVLCを起動して再生するだけではないことを考えると何もない、一言で正確に説明できると思います。 ウィンクする
RAMはほぼ1GBですが、何もしませんか？これについて何ができますか？少ないものを探してください、eh、貪欲メモリ？