기사 를 읽고 있었는데 CPU가 비디오 압축에 더 좋다는 것을 알았습니다. GPU보다.
이 기사에서는 프로세서가 GPU보다 복잡한 알고리즘을 처리 할 수 있기 때문에 이런 일이 발생한다고 말합니다.하지만 좀 더 기술적 인 설명을 원하고 인터넷에서 검색을 몇 번 해봤지만 그렇지 않았습니다. 무엇이든 찾을 수 있습니다.
자, 사이트를 설명하거나 링크하는 것을 아는 사람이 더 자세한 설명을 받았습니까?
답변
링크 한 기사가 그다지 좋지 않습니다.
일반적으로 단일 패스 비트 레이트 인코딩은 비트 레이트를 RF 값으로 변환합니다. 최대 비트 전송률 제한을 가져옵니다.
x264 “의 1 회 통과 ABR 속도 제어는 CRF + 제한으로 구현되지 않습니다. 그는 2 패스가 맞습니다. 하지만 목표 비트 전송률을 달성하는 가장 좋은 방법입니다.
그리고 그는 분명히 그가 x264를 쓰레드 = 3 등으로 시작할 수 있다는 것을 깨닫지 못했습니다. 다른 작업을 위해 약간의 CPU 시간을 남겨 두십시오. 또는 x264 “의 우선 순위를 매우 낮음으로 설정하여 다른 작업이 원하지 않는 CPU 시간 만 얻습니다.
또한 그는 스레드 = 1을 CUDA 또는 기타 사용과 혼합합니다. 질문이있는 것은 당연합니다. 기사에 끔찍한 설명이 있습니다. 전체 기사는 기본적으로 x264 --preset veryslow --tune film --crf 26 in.m2ts --out out.mkv를 사용하거나 입력 AviSynth 스크립트와 함께 일부 라이트 필터링을 사용하는 것으로 요약됩니다. 그는 실제로 플라시보 “. 그거 웃기 네요. 위약으로 인코딩 된 불법 복제 파일을 본 적이 없습니다. (iv id = “대신 me=esa 또는 me=tesa에서 알 수 있습니다. aecffbf258 “>
모든 양질의 사전 설정 (최대veryslow)
또한 10 비트 색상 심도 사용에 대해서는 언급하지 않았습니다. 인코딩 및 디코딩이 가능하지만 8 비트로 다시 다운 컨버팅 한 후에도 더 나은 8 비트 SSIM을 얻을 수 있습니다. 모션 벡터에 대해 더 많은 정밀도를 사용하면 분명히 도움이됩니다. 또한 정확히 전체 8 비트 값으로 반올림하지 않아도 도움이됩니다. 8을 생각할 수 있습니다. 속도 해킹으로 구성 요소 당 비트, 주파수 영역에서 양자화 한 다음 CABAC로 압축하면 더 높은 비트 깊이 계수가 더 많은 공간을 차지할 필요가 없음을 의미합니다.
(BTW, h. 265는 이미 모션 벡터에 대한 정밀도가 더 높기 때문에 8 비트 비디오에 대한 10 비트 인코딩의 이점이 적습니다. 8 비트 비디오 입력에 10 비트 x265를 사용하는 것이 이점이 있다면 x264보다 작습니다. 따라서 속도 패널티가 발생할 가능성이 적습니다. 그럴만 한 가치가 있습니다.)
실제 질문에 답하려면 :
편집 : doom9이 다시 시작되었으므로 링크를 정리하겠습니다. 누가 뭐라고 말했는지 적절한 인용문으로 이동하세요.
http://forum.doom9.org/showthread.php?p=1135399#post1135399
Google은 인용문을 제대로 표시하지 않는 어리석은 인쇄 버전 만 캐시합니다. 이러한 메시지 중 어떤 부분이 인용문인지, 어떤 부분이 그 사람 자신의 원인인지 잘 모르겠습니다.
매우 불규칙한 분기 패턴 (건너 뛰기 모드) 및 비트 조작 (양자화 / 엔트로피 코딩)은 현재 GPU에 적합하지 않습니다. IMO는 유일한 현재 정말 좋은 애플리케이션은 전체 검색 ME 알고리즘입니다. 결국 가속 전체 검색은 CPU보다 빠르더라도 여전히 느립니다.
-MfA사실 기본적으로 CABAC를 제외한 모든 작업을 GPU에서 합리적으로 수행 할 수 있습니다 (이 작업은 병렬화 할 수 없음).
x264 CUDA는 fullpel을 구현합니다. 처음에는 서브 펠 ME 알고리즘을 사용합니다. 나중에는 비트 비용 방식으로 RDO와 같은 작업을 수행 할 수 있습니다. CABAC 대신 ximation.
단 정밀도 부동 소수점에서 모든 작업을 수행해야하기 때문에
-MfA잘못된 CUDA는 정수 수학을 지원합니다.
-Dark Shikari
Dark Shikari x264 메인테이너이자 2007 년 이후 대부분의 기능 개발자입니다.
AFAIK,이 CUDA 프로젝트는 성공하지 못했습니다. OpenCL을 사용하여 미리보기 스레드에서 일부 작업을 오프로드 할 수 있도록 지원합니다 (프레임의 고품질 최종 인코딩이 아닌 빠른 I / P / B 결정).
내 이해 는 비디오 인코딩을위한 검색 공간이 너무 커서 CPU에서 검색 경로의 조기 종료를위한 스마트 휴리스틱이 무차별 대입 GPU를 능가한다는 것입니다. 최소한 고품질 인코딩을 위해 테이블로 가져 오십시오. x264보다 합리적으로 HW 인코딩을 선택할 수있는 -preset ultrafast와 비교됩니다. 특히 CPU가 느린 경우 (예 : 듀얼 코어가 있고 하이퍼 스레딩이없는 노트북). CPU (하이퍼 스레딩이있는 i7 쿼드 코어), x264 superfast는 아마도 속도가 빠르며 더 좋아 보일 것입니다 (동일한 비트 전송률에서).
속도 왜곡 (파일 크기 당 품질)이 중요한 부분에서 인코딩을 만드는 경우 x264 -preset medium 이하를 사용해야합니다. 무언가를 다시 보관하고 CPU 시간을 조금 더 소비하면 “파일을 보관하는 한 바이트를 절약 할 수 있습니다.
참고 사항, 비디오 포럼에서 deadrats의 메시지를 본다면 그것은” 도움이되지 않을 것입니다. 그는 내가 본 모든 스레드에서 그가 말하는 대부분의 항목에 대해 틀 렸습니다. 그의 게시물은 내가 x264 GPU 인코딩에 대해 검색 한 몇 개의 스레드에서 나타났습니다. 분명히 그는 이것이 왜 쉽지 않은지 이해하지 못합니다. x264 개발자에게 왜 “멍청한 지 …
답변
2017 업데이트 :
p>
ffmpeg는 h264 및 h265 NVENC GPU 가속 비디오 인코딩을 지원합니다 . hevc_nvenc 또는 h264_nvenc에 대해 선택한 품질로 1 패스 또는 2 패스 인코딩을 수행 할 수 있습니다. 심지어 보급형 GPU를 사용하더라도 비가 속 인코딩 및 Intel Quick Sync 가속 인코딩보다 훨씬 빠릅니다.
2 패스 고품질 인코딩 :
ffmpeg -i in.mp4 -vcodec h264_nvenc -preset slow out.mp4 1 패스 기본 인코딩 :
ffmpeg -i in.mp4 -vcodec h264_nvenc out.mp4 NVENC ffmpeg 도움말 및 옵션 :
ffmpeg -h encoder=nvenc 사용하세요. CPU 인코딩보다 훨씬 빠릅니다.
GPU가없는 경우 Intel Quick Sync 코덱, h264_qsv, hevc_qsv 또는 mpeg2_qsv를 사용할 수 있습니다.이 코덱은 비가 속 인코딩보다 훨씬 빠릅니다.
댓글
답변
Peter가 말한 내용에 대해 좀 더 자세히 설명하려면 일반적으로 여러 개의 프로세서를 사용하면 여러 개의 독립적 인 작업이있는 경우에 도움이됩니다. 수행해야하지만 서로에 대한 종속성이 없거나 방대한 양의 데이터에 대해 동일한 수학을 수행하는 하나의 작업입니다.
그러나 계산 A의 출력이 필요한 경우 계산 B의 입력으로, 계산 B의 출력을 계산 C의 입력으로 사용하면 각 작업 (A, B 또는 C)에 대해 서로 다른 핵심 작업을 수행하여 속도를 높일 수 없습니다. 다른 작업이 끝날 때까지 시작합니다.
그러나 위의 경우에도 o 다른 방법으로 병렬화하십시오. 입력 데이터를 청크로 분할 할 수있는 경우 A, B, C를 한 데이터 청크로 수행하고 다른 코어는 A, B, C를 다른 데이터 청크에서 수행하는 데 하나의 코어 작업을 수행 할 수 있습니다. .
다른 고려 사항도 있습니다. 계산을 병렬화하는 방법을 찾을 수 있지만 디스크 또는 네트워크를 통해 데이터를 읽거나 GPU로 전송하는 것은 계산을 수행하는 것보다 더 오래 걸립니다. 이 경우 데이터를 메모리로 가져 오는 것만으로도 계산을 병렬로 수행하여 절약하는 시간보다 오래 걸리기 때문에 병렬화하는 것은 의미가 없습니다.
즉, 예술만큼이나 과학입니다.
댓글
- 예, x264는 멀티 코어 CPU에서 매우 잘 병렬화됩니다. 저는 거의 선형 적으로 최소 8 개 코어까지 확장하고 32 개를 넘어도 괜찮습니다. 모션 추정은 병렬로 수행 할 수 있으며 다른 스레드에 대해 반드시 직렬 작업 만 남겨두고 유사한 트릭을 남깁니다.
- 질문은 다음과 같습니다. ‘ 일반적으로 병렬 처리가 아니라 ‘ 특히 GPU입니다. ‘ 실행할 수있는 코드는 CPU보다 훨씬 더 제한적입니다. 이미지의 다른 블록에서 다른 방식으로 이동하는 브랜치가있는 코드를 ‘ 할 수 없기 때문에 ‘라고 생각합니다. 나는 ‘ 이유를 정확히 이해하지 못하지만 ‘ 그런 것 같습니다. 각 스트림 프로세서는 매우 간단하고 다른 것과 독립적으로 실행되도록하는 제한된 수단으로 인해 가장 느린 프로세서가 완료 될 때까지 항상 기다려야하거나 분기에 제한이 있거나 둘 다입니다.
- 컴퓨터 클러스터 (메모리 대역폭 및 CPU 캐시에 대해 서로 경쟁하지 않는 ‘ 독립 RAM이있는 CPU)가있는 경우 ‘ d는 입력 비디오를 GOP로 나누고 여전히 압축 된 입력 비디오의 섹션을 전송하여 클러스터의 다른 시스템에서 디코딩 및 압축합니다.따라서 압축 된 입력 또는 출력 비디오 만 전송하면됩니다. 멀티 소켓 x86 워크 스테이션과 같은 멀티 코어 공유 캐시 / RAM 시스템에서는 여러 스레드가 한 번에 동일한 프레임에서 작동합니다. (또한 인코딩 세그먼트 화를위한 글로벌 속도 제어를 수행하기 위해 ‘ 새 코드가 필요하지 않음을 의미합니다.)
-c:v libx264 -preset slower를 이길 수 없습니다 (Skylake i7-6700k에서 1920x1080p24에 대한 거의 실시간처럼 느리지 않습니다.)ffmpeg를-vcodec h264_qsv와 함께 사용하면 렌더링 속도가 훨씬 빨라졌습니다!