GPU보다 인코딩에 프로세서가 더 나은 이유는 무엇입니까?

이 기사를 읽고 CPU가 비디오 압축에 GPU보다 낫다는 것을 알았습니다.

이 기사는 프로세서가 GPU보다 복잡한 알고리즘을 처리 할 수 ​​있기 때문에 발생한다고 기술하지만 더 기술적 인 설명을 원합니다. 인터넷에서 검색을했지만 아무것도 찾지 못했습니다.

그래서 누군가 내가 사이트에 대해 설명하거나 링크를 알고 있다는 것을 알고 있습니까?

연결 한 기사가 그리 좋지 않습니다.

일반적으로 단일 패스 비트 전송률 인코딩은 비트 전송률을 최대 비트 전송률 제한이있는 RF 값으로 변환하여 가져옵니다.

x264의 1 패스 ABR 속도 제어는 CRF + 한계로 구현되지 않습니다. 그래도 2 패스가 대상 비트 전송률을 달성하는 가장 좋은 방법이라는 것은 맞습니다.

그리고 그는 다른 작업을 위해 CPU 시간을 자유롭게 남겨두기 위해 스레드 = 3 또는 다른 것으로 x264를 시작할 수 있음을 알지 못합니다. 또는 x264의 우선 순위를 매우 낮게 설정하면 다른 작업에서 원하지 않는 CPU 시간 만 가져옵니다.

또한 CUDA 또는 다른 것을 사용하여 스레드 = 1을 섞습니다. 기사에 끔찍한 설명이 있기 때문에 궁금한 점이 없습니다. 전체 기사는 기본적으로 use x264 --preset veryslow --tune film --crf 26 in.m2ts --out out.mkv, 또는 입력 AviSynth 스크립트로 일부 라이트 필터링을 사용합니다. 그는 실제로 "위약"을 추천합니다. 재밌 네요. 위약으로 인코딩 된 불법 복제 된 파일을 본 적이 없습니다. ( 모든 양질의 사전 설정 대신 me=esa또는 에서 (으)로 알 수 있습니다 .me=tesame=umhveryslow

또한 10 비트 색심도 사용에 대해서는 언급하지 않았습니다. 인코딩 및 디코딩 속도가 느리지 만 다시 8 비트로 다시 변환 한 후에도 8 비트 SSIM이 향상됩니다. 모션 벡터의 정밀도를 높이면 분명히 도움이됩니다. 또한 정확히 8 비트 값으로 반올림하지 않아도 도움이됩니다. 구성 요소 당 8 비트를 속도 핵으로 생각할 수 있습니다. 주파수 영역에서 양자화 한 다음 CABAC로 압축한다는 것은 높은 비트 깊이 계수가 더 많은 공간을 차지할 필요가 없다는 것을 의미합니다.

(BTW, h.265는 모션 벡터에 대해 이미 정밀도가 높기 때문에 8 비트 비디오에 대한 10 비트 인코딩의 이점이 적습니다. 8 비트 비디오 입력에 10 비트 x265를 사용하는 이점이있는 경우 따라서 속도 패널티가 그만한 가치가 없을 것입니다.)

실제 질문에 대답하려면 :

편집 : 이제 doom9가 다시 시작되었으므로 링크를 정리하겠습니다. 누가 무엇을 말했는지에 대한 적절한 인용을 위해 그것에 가십시오.

http://forum.doom9.org/showthread.php?p=1135399#post1135399

Google은 따옴표를 제대로 표시하지 않는 바보 같은 인쇄 버전 만 캐시합니다. 나는이 메시지들 중 어떤 부분이 인용문인지, 그리고 그 자체가 인용 된 것인지 확실하지 않습니다.

매우 불규칙적 인 분기 패턴 (건너 뛰기 모드) 및 비트 조작 (양자화 / 엔트로피 코딩)은 현재 GPU에 적합하지 않습니다. IMO가 현재 유일하게 좋은 응용 프로그램은 전체 검색 ME 알고리즘입니다. 결국 전체 검색 속도는 CPU보다 빠르더라도 여전히 느립니다.
-MfA

실제로 기본적으로 CABAC를 제외하고 GPU에서 모든 것을 합리적으로 수행 할 수 있습니다 (수행 할 수는 있지만 병렬화 할 수는 없습니다).

x264 CUDA는 처음에 fullpel 및 subpel ME 알고리즘을 구현합니다. 나중에 CABAC 대신 비트 비용 근사치로 RDO와 같은 작업을 수행 할 수 있습니다.

단 정밀도 부동 소수점에서 모든 작업을 수행해야하기 때문에
-MfA

잘못된 CUDA는 정수 수학을 지원합니다.

-다크 시카 리

Dark Shikari는 x264 관리자이자 2007 년 이후 대부분의 기능을 개발 한 개발자입니다.

AFAIK,이 CUDA 프로젝트는 전개되지 않았습니다. 룩어 헤드 스레드에서 일부 작업을 오프로드하기 위해 OpenCL을 사용할 수 있습니다 (프레임의 고품질 최종 인코딩이 아닌 빠른 I / P / B 결정).

나의 이해는 비디오 인코딩을위한 검색 공간은 CPU에서 검색 경로의 조기 종료에 대한 스마트 추론이 무차별 GPU는 높은 품질의 인코딩 적어도, 테이블에 가져다 이길 수 있도록 큰 것입니다. -preset ultrafastx264보다 HW 인코딩을 합리적으로 선택할 수있는 곳 과 비교됩니다 . CPU가 느린 경우 (듀얼 코어가 있고 하이퍼 스레딩이없는 랩톱과 같은) 빠른 CPU (하이퍼 스레딩 기능이있는 i7 쿼드 코어)에서 x264 superfast는 속도가 빠를 것입니다 (같은 비트 전송률에서).

전송률 왜곡 (파일 크기 당 품질)이 중요한 인코딩을 만드는 경우 x264 -preset medium이하 를 사용해야합니다 . 무언가를 보관하는 경우 이제 조금 더 많은 CPU 시간을 소비하면 해당 파일을 유지하는 한 바이트를 절약 할 수 있습니다.

참고로, 비디오 포럼에 교착 상태 메시지가 표시되면 도움이되지 않습니다. 그는 내가 본 모든 실에서 그가 말하고있는 대부분의 것들에 대해 틀렸다. 그의 게시물은 x264 GPU 인코딩에 대해 Google에서 검색 한 몇 개의 스레드로 나타났습니다. 분명히 그는 왜 쉽지 않은지 이해하지 못하고 x264 개발자에게 왜 바보인지 왜 알기 위해 여러 번 게시했습니다 ...

2017 년 업데이트 :

ffmpeg는 h264 및 h265 NVENC GPU 가속 비디오 인코딩을 지원 합니다. hevc_nvenc 또는 h264_nvenc에 대해 선택한 품질로 1 패스 또는 2 패스 인코딩을 수행 할 수 있으며 엔트리 레벨 GPU의 경우에도 가속되지 않은 인코딩 및 인텔 빠른 동기화 가속 인코딩보다 훨씬 빠릅니다.

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의 입력으로 계산 A의 출력과 계산 C의 입력으로 계산 B의 출력이 필요한 경우 각 작업에서 다른 핵심 작업을 수행하여 속도를 높일 수 없습니다 ( 다른 하나가 끝날 때까지 시작할 수 없기 때문에 A, B 또는 C).

그러나 위의 경우에도 다른 방법으로 병렬화 할 수 있습니다. 입력 데이터를 청크로 나눌 수 있다면 A, B, C를 하나의 데이터 청크로 수행하는 핵심 작업이 있고 다른 코어는 A, B, C를 다른 데이터 청크로 수행하는 작업을 수행 할 수 있습니다. .

다른 고려 사항도 있습니다. 계산을 병렬화하는 방법을 찾을 수는 있지만 디스크 나 네트워크를 통해 데이터를 읽거나 GPU로 전송하는 것은 계산을 수행하는 것보다 시간이 오래 걸립니다. 이 경우 병렬로 계산을 수행하여 데이터를 메모리에 저장하는 것보다 시간이 오래 걸리기 때문에 병렬화하는 것은 의미가 없습니다.

다시 말해, 그것은 과학만큼이나 예술입니다.