2개의 인스턴스가 실행 중입니다 vlc. 한 명은 놀고 있어요. 그 중 하나가 일시 중지되었습니다(대부분이 교체되었습니다).
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개의 대형 비디오로 1280x720 재생"에 대한 그래프입니다( ps aux초당 600초로 측정).
다음은 "목록에 0개의 큰 비디오가 있는 1280x720 재생"에 대한 그래프입니다( ps aux100초당 초 단위로 측정).
이는 "목록에서 0"의 사용이 약간 과대평가되었음을 의미합니다. RSS는 시작 직후 최고조에 달하고 15초 후에 약간 떨어집니다.
VSize는 항상 RSS보다 2.3GB 더 큽니다.
목록에 5400개의 비디오가 있는 640x360 재생: 최대 상주 세트 크기(킬로바이트): 1096232
목록에 5400개의 비디오가 있는 640x360 일시중지: 최대 상주 세트 크기(킬로바이트): 1101840
목록에 0개의 비디오가 있는 640x360 재생: 최대 상주 세트 크기(킬로바이트): 333228
일시중지됨 640x360, 목록에 동영상 0개: 최대 상주 세트 크기(킬로바이트): 303792
목록에 2087개의 대형 비디오가 있는 1280x720 재생: 최대 상주 세트 크기(킬로바이트): 1273936
일시정지 1280x720, 목록의 대형 비디오 2087개: 최대 상주 세트 크기(킬로바이트): 1190252
목록에 0개의 비디오가 있는 1280x720 재생: 최대 상주 세트 크기(킬로바이트): 185204
일시중지됨 1280x720, 목록에 동영상 0개: 최대 상주 세트 크기(킬로바이트): 185352
이는 재생목록이 RSS에 큰 영향을 미치는 반면 비디오 해상도는 그렇지 않음을 나타내는 것 같습니다.
이유는 불분명합니다.
VLC는 각 비디오의 길이를 명확하게 캐시합니다. 비디오의 길이가 목록에 천천히 나타나며 이는 그림에 표시된 것처럼 메모리가 느리게 증가하는 것을 설명합니다. 그러나 길이는 몇 바이트에 불과합니다. VLC가 무엇을 하든 목록의 각 비디오는 150kb-500kb의 상주 RAM을 차지합니다.
1280x720을 재생하려면 200MB RSS가 합리적이라고 생각했지만 800MB RSS를 추가하지 않으면 재생 목록이 RAM에 유지됩니다.
VLC에 RAM에 캐시하지 않고 목록을 유지하도록 요청할 수 있나요?
답변1
이는 상대적으로 타당해 보입니다. 즉, 우리가 소프트웨어 디코딩을 수행하고 있고(즉, 하드웨어에서 디코딩하기 위해 사전 처리된 비디오 데이터를 GPU 버퍼로 보내는 것이 아니라) Full HD를 다루고 있으며 MPEG4 시대를 다루고 있다고 가정할 때입니다. 코덱 장치.
그런 다음 다음 프레임이 충분히 멀리 전송될 수 있도록 쉽게 렌더링되는(즉, 그래픽 카드로 전송할 수 있는(또는 여기에서 출력 역할을 수행하는 모든 항목에 의해 처리되는) 정적 이미지 형식으로 분할된) 일부 프레임을 유지해야 합니다. 재생 시 지연이 없을 것입니다. 특히 혼잡한 CPU에서 소프트웨어 디코딩이 발생하는 경우 미리 많은 프레임을 계산하여 RAM에 기록한 다음 OS가 스레드에서 또는 그 이전에 시간을 다시 예약하기를 바랍니다. 현재 표시된 이미지를 변경하여 화면을 업데이트하는 하드웨어 유닛이 완성되었습니다.
이제 24비트 깊이의 Full HD 프레임(이것이 사용된 텍스처 형식이라고 가정하지만 그럴 가능성이 높음)은 약 6MB입니다. 이것이 약 1/4초 버퍼에 불과하다는 점을 고려하면 전송/비트 차단을 위해 약 100MB의 이미지를 준비하는 것은 낭비처럼 들리지 않습니다.
그러나 해당 프레임을 렌더링하려면 많은 작은 기본 콘텐츠로 구성된 비디오를 디코딩해야 합니다(MPEG-2 및 기타 콘텐츠는 일부 계수를 덜 양자화할 수 있는 일부 변환을 통해 작은 이미지 청크를 처리한다는 점에서 JPEG와 다르지 않다고 생각하세요) 따라서 압축됨)뿐만 아니라 상대 모션 맵(1/4 픽셀 해상도에서도 모션 보상) 및 멀리 떨어져 있는 프레임 간의 보간과 같은 매우 장거리 항목도 포함됩니다. MPEG-4 AVC(H.264)는 최대 16개의 참조 프레임을 사용합니다. 새로운 프레임을 얻기 위해 결합합니다.
이는 개별 프레임을 다른 방식으로 사용해야 할 수 있으므로 여전히 필요한 참조 프레임보다 더 큰 중간 결과가 생성될 수 있음을 의미합니다.
이제 나는 600MB보다 작은 버퍼를 사용하여 디코더를 작성하는 것이 가능해야 한다는 데 동의하지만 (디코더에 대한 실제 통찰력 없이) 다른 프레임에서 재사용할 수 있는 중간 결과가 있을 수 있다고 추측합니다. , 대부분의 경우 메모리 풀로 돌아가거나 나중에 덮어씁니다. 이는 디코딩 메모리를 "부풀게"하지만 성능에는 좋습니다.
답변2
범인을 찾았습니다.
도구 > 환경 설정 > 디스플레이 설정 > 전체 > 재생 목록 > 자동으로 항목 준비
이 옵션을 켜면 VLC는 재생 목록의 각 파일을 읽고 비디오 길이를 찾습니다. 분명히 그것은 또한 더 많은 것을 읽습니다.
비활성화하면 문제가 사라졌고(VLC는 200MB 미만으로 유지됨) 다시 활성화하면 문제가 다시 나타났습니다.
나에게 이것은 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,탐욕스러운메모리?