고속 I/O 장치에서 실시간 재생 및 스트리밍 재생

RV는 2k 이상을 고속 I/O 장치에서 직접 읽을 수 있는 다양한 기능을 갖추고 있습니다. I/O 및 디코딩 속도를 결정하는 몇 가지 변수가 있기 때문에 RV에서 간단한 매개변수 세트로 시작해 보고, 한 번에 하나씩 조정해야 합니다. 동시에 모든 매개변수를 조정하면 최적의 지점을 찾아내기가 훨씬 어려워집니다.

적절한 시기에 자세한 정보로 이 내용을 업데이트할 예정입니다.

빠른 시작

 RV는 아티스트 데스크톱에서 가장 자주 사용되고 있기 때문에 기본 설정이 스트리밍 I/O에 맞게 구성되어 있지 않습니다. 스트리밍 I/O를 가능하게 하는 가장 중요한 변화가 여기에 나열되어 있습니다. 자세한 내용과 기타 옵션은 아래에 설명되어 있습니다.

  1. 미리보기 캐시 켜기
  2. RV 기본 설정에서 리더 스레드 수 늘리기(최적의 수를 찾기 위한 실험)
  3. 필요하다면 포맷별 이미지 기본 설정에서 대체 I/O 방식 시도
  4. 기본 설정(Preferences)->렌더링(Render) 섹션에 있는 미리 가져오기 사용(PBO 켬 또는 끔 상태)
  5. Linux에서 -scheduler SCHED_RR -priorities 99 99(아래 참조)를 통해 RV를 루트로 실행하여 소프트 실시간으로 재생 

시스템 요구 사항

권장 시스템은 따로 없습니다. 사람들은 서로 다른 다양한 설정을 사용하여 스트리밍 재생을 실행하고 있습니다. 하지만 다음 사양을 갖추고 있다면 확실히 이점이 있습니다.

  • 복수 코어 + 프로세서
  • 많은 메모리(64비트 컴퓨터에서는 6GB가 이상적)
  • 64비트 컴퓨터
  • 최신 GPU(항상 Quadro일 필요는 없음)
  • 준수한 마더보드 
  • RAID, ioXTREME 등의 고속 I/O 장치 ("고속" 디스크 드라이브 하나로는 부족할 수 있음)
  • NVidia 카드. Cheapo 580 Quadro도 충분하지만 최신 사양이면 더욱 원활. 최신 Geforce 카드 역시 충분

스트리밍 I/O 이미지 형식

스트리밍은 이 형식에서만 가능합니다. 이 형식과 다른 형식으로 가능하게 한다면 그건 정말 기적입니다.

  • DPX 및 Cineon -- 특히 10비트 파일
  • JPEG
  • TARGA(TGA)
  • TIFF -- 주로 RAW tiff가 최선, 비압축
  • EXR 또는 ACES

복수 리더 스레드

고속 I/O 스트리밍을 위해서는 복수 리더 스레드를 사용해야 합니다. 이렇게 하려면 룩 어헤드(look-ahead) 캐시를 사용해야 합니다. 룩 어헤드(look-ahead) 캐시 크기로는 가능한 가장 작은 값을 사용하는 것이 좋습니다. 간혹 1GB 이상(때로는 그 이상)이 좋다는 사람들도 있습니다. 하지만 이상적으로는 1GB 이상이 아닙니다. 

최소 두 개의 코어를 사용할 수 있는 것이 아니라면 아마 스트리밍 재생이 안 될 것입니다.

스레드 두 개로 시작하십시오. 스레드 두 개로 속도를 최적화한 후에 수를 늘려 가십시오. 스레드 수는 캐싱 탭의 기본 설정에서 조정할 수 있습니다. 스레드 수를 변경한 다음에는 RV를 다시 시작해야 합니다.

코어 및 프로세서가 많을수록 좋고, 메모리도 클수록 좋습니다.

복수 EXR 디코딩 스레드

EXR 파일을 스트리밍하려면 디코딩을 위해 코어 일부를 예약해야 합니다. EXR 디코딩 스레드 수는 형식 탭의 기본 설정에서 변경할 수 있습니다. "자동"을 먼저 시도해 보십시오.

I/O 방식

시험 없이 어떤 I/O 방식을 사용할지 결정하기는 어렵습니다. I/O 방식은 기본 설정 형식 탭에서 변경할 수 있습니다. 기본 I/O 방식은 다음과 같습니다.

  • 표준(일부 형식용). 이 방식은 해당 파일을 읽는 표준 또는 일반 방식으로 여겨지는 방식입니다. EXR을 예로 들면 이는 EXR 라이브러리의 일부로 제공되는 "일반" EXR I/O 스트림을 사용합니다.
  • 버퍼드. 데이터가 모든 데이터의 단일 논리적 읽기로 "스트리밍"됩니다. 커널이 그렇게 결정한다면 파일 데이터가 파일 시스템 캐시에 상주할 수 있습니다. 모든 데이터를 읽은 후에 파일 데이터가 디코딩됩니다.
  • 언버퍼드. 버퍼드와 유사하지만 파일 데이터를 파일 시스템 캐시에 배치하면 안 된다는 힌트를 RV가 커널에 제공한다는 점만 다릅니다. 이론상 이 방식에서는 읽기 중 데이터 사본이 생성되지 않기 때문에 I/O 속도가 더 빨라질 수 있지만 실제로는 속도 향상에 도움이 되는 경우를 보지 못했습니다. 언버퍼드 I/O의 유용성을 두고 인터넷상에서 많은 갑론을박이 펼쳐지고 있습니다. 
  • 메모리 매핑. 파일 컨텐츠가 메인 메모리에 직접 매핑됩니다. 이 방식은 파일 시스템 캐시 방식이 아니고, 더 이상 필요하지 않으면 프로세스가 메모리를 쉽게 회수할 수 있다는 이점이 있습니다. 어떤 점에서는 위에 나온 버퍼드 방식과 비슷합니다. Windows에서는 이 방식이 위의 버퍼드, 언버퍼드 및 표준 방식에 비해 로컬 I/O 속도를 크게 높여줄 수 있습니다.
  • 비동기 버퍼드. 위의 버퍼드와 유사하지만 커널이 데이터가 순서대로 정렬되기를 기다리지 않고 무작위 순서로 RV에 데이터를 제공할 수 있습니다. 또한 저레벨 I/O 청크 크기를 사용하여 대역폭을 극대화하도록 I/O를 미세 조정할 수 있습니다. Windows에서는 이 방법이 가장 유용합니다. Linux 및 Mac에서는 비동기 I/O가 RV와 관련하여 유용하지 않은데, 그 이유는 RV가 디코딩 및 읽기를 동시에 직접 관리하기 때문입니다.
  • 비동기 언버퍼드. 비동기 버퍼드와 같지만 가능하다면 데이터를 파일 시스템 캐시에 저장하는 과정을 생략하도록 커널에 힌트가 제공된다는 점이 다릅니다. Windows에서는 이 방식이 기본입니다.

경험에 따른 규칙

  • 기본 설정의 미리 가져오기 옵션을 사용하십시오. 그러면 필요한 VRAM의 용량이 두 배가 되지만 RV와 그래픽 카드 간 대역폭이 크게 증가할 수 있습니다. 이는 특히 스테레오를 볼 때 중요합니다. PBO(Pixel Buffer Object)도 켜는 것이 이상적입니다. 최신 그래픽 카드는 PBO를 켜면 성능이 향상됩니다. 이전 버전의 카드는 켰다가 껐다가 하면서 시험해 보아야 합니다. Fermi 이전 세대의 일부 Quadro 카드는 이 기능을 켰을 때 오히려 성능이 나빠질 수 있습니다.
  • NVIDIA Quadro Fermi 및 Kepler GPU(Fermi 4000, 6000, Kepler 4000, 5000, 6000)는 Linux 및 Windows에서 멀티스레드 GPU 업로드를 지원합니다 . Mac에서는 Apple 클라이언트 스토리지를 지원합니다.
  • Windows에서는 비동기 언버퍼드를 먼저 시도해 보십시오. 좋은 결과를 낼 수 있는 유일한 다른 방식은 메모리 매핑 방식입니다.
  • Linux에서는 메모리 매핑이 불규칙한 재생(특히 소프트웨어 RAID 사용 시)을 유발할 수도 있습니다. 언버퍼드 또는 버퍼드 방식이 기본 방식이지만 메모리 매핑 방식도 문제만 없다면 훌륭한 옵션입니다.
  • 언버퍼드 방식은 Linux에서 플라세보 효과를 일으킬 수 있습니다. 이는 데이터를 읽어 오는 파일 시스템의 유형에 따라 정해지는 것으로 보입니다. ext4 지원 Ubuntu 10.04를 예로 들면 버퍼드 방식과 동일한 것으로 보이지만 실제로는 NFS에서 역효과를 낳을 수도 있습니다.
  • EXR의 경우 표준 방식을 사용하지 마십시오. 언버퍼드 방식은 대개 파일 시스템이 이를 지원하는 경우에 최선의 방식입니다.
  • EXR B44 이미지는 이상적으로는 4:2:0으로 서브샘플링됩니다. B44/A는 16비트여야 한다는 점도 염두에 두십시오. PIZ, ZIP 및 ZIPS 인코딩 EXR은 CPU 집약적이며, 더 많은 EXR 디코더 스레드가 필요할 수 있습니다.
  • 최신 그래픽 카드가 있다면 형식 기본 설정에서 DPX 및 Cineon 10비트 디스플레이 깊이를 10 Bits/Pixel Reversed로 설정해 보십시오. 이 옵션이 RV에서 10비트 데이터를 처리하는 가장 빠르고 가장 색상 보존도가 뛰어난 방식입니다. HP Dreamcolor 같은 "30비트" 지원 모니터가 있다면 추가로 X 서버 또는 Windows를 30비트 모드로 놓고 고정밀도 색상과 고속 스트리밍 효과를 모두 누릴 수 있습니다.
  • 10비트 DPX를 16비트 모드로 표시하려면 I/O 장치에서 그래픽 카드로의 대역폭이 8비트 모드에서보다 2배 더 필요합니다. DPX/Cineon에 대해 10비트 모드를 사용할 수 있다면 8비트를 먼저 시도해 보십시오.
  • I/O 장치의 지연 시간이 큰 경우 지연을 줄이려면 리더 스레드 수를 크게 늘려야 할 수 있는데, 코어보다 많은 스레드를 사용하는 것이 좋은 경우도 있습니다. 이 현상은 네트워크 스토리지에서 발생할 수 있습니다.
  • RV의 V-Sync가 드라이버의 GL V-Sync와 같이 동시에 켜져 있지 않도록 하십시오.
  • 픽셀 데이터가 4096 바이트로 시작하도록 파일에 작성하는 DPX 파일은 리틀 엔디언(Little-endian)이고, 4채널 8비트, 3채널 10비트 또는 4채널 16비트를 사용하며, 해상도 폭이 8로 분할 가능합니다.
  • 모든 속도 테스트에서 "실시간(Realtime)"이 아닌 "모든 프레임 재생(Play All Frames)" 모드(Control men)인지 확인하십시오. 여기에서 "실시간(Realtime)"은 RV가 비디오 프레임을 건너뛰어 오디오와 속도를 맞추는 것을 의미합니다.
  • 모든 파일 시스템에서 모든 I/O 방식이 지원되는 것은 아닙니다. 특히 언버퍼드 I/O 방식은 기본 파일 시스템 구현에서는 지원되지 않을 수 있습니다.

테스트 및 파일 시스템 캐시 관련 참고 사항

모든 운영 체제(RV 실행)는 파일 시스템에서 일부 페이지를 메모리에 유지함으로써 IO 처리량을 극대화하려고 합니다. 이 알고리즘은 예측이 정말 어렵지만 그 결과는 실시간 스트리밍 IO 성능을 테스트하려 한다면 이 OS의 "지원" 때문에 숫자는 아무 의미 없어진다는 것입니다. 다시 말해, 테스트를 하려면 메모리에서 아무런 시퀀스도 재생되지 않는 상태에서 각각의 테스트 케이스를 시작해야 합니다. 그 한 가지 방법은 매우 큰 테스트 세트를 사용하는 것입니다. 즉, 여러 시퀀스를 사용하는데 각각 수천 개의 프레임으로 이루어진 시퀀스를 사용하는 것입니다. 프레임이 충분히 크고 RAM이 아주 적은 경우 각 테스트 케이스에서 새 시퀀스로 전환하면 새 시퀀스에서 이미 파일 시스템 캐시에 포함된 부분은 전혀 없게 됩니다.

하지만 프레임 중 어느 부분도 메모리에 포함되지 않도록 하면서 같은 시퀀스를 계속해서 테스트할 수 있는 보다 확실한 방법은 각 테스트 케이스를 실행하기 전에 파일 시스템 캐시를 강제로 지우는 것입니다. Linux에서는 이 명령을 실행할 수 있습니다.

sudo echo 1 > /proc/sys/vm/drop_caches

Mac OSX에서는 이 명령을 실행합니다.

purge

아쉽게도 Windows에서는 파일 시스템 캐시를 지우는 방법을 모릅니다. 여러분이 알고 있다면 공유해 주십시오!

실시간

RV 버전 3.10.8의 경우 Linux에서 RV로 하여금 실시간 응용프로그램으로 실행되도록 할 수 있습니다. 이 모드를 이용하면 Linux에서 가장 안정적인 재생이 가능합니다. 특히 컴퓨터가 서버 타임 슬라이스 지속 시간으로 설정된 경우에 그러합니다(대개 컴퓨터를 최대 처리량을 위해 미세 조정할 때의 상황). 이상적이라면 RV는 최소 디스플레이 및 오디오 스레드에 대해서는 더 많고 더 작은 타임 슬라이스로 실행되는 것입니다.

이 모드로 RV를 시작하려면 다음을 사용합니다.

rv -scheduler SCHED_RR -priorities 99 99

RV Linux는 FIFO 또는 Round Robin 스케줄러를 시도 및 사용합니다(이 경우 일반 Linux 스케줄러 대신). 이렇게 하려면 CAP_SYS_NICE 성능을 갖고 있어야 합니다. 이는 다양한 방식으로 가능하지만 현재로서는 두 가지 방식만 실행할 수 있습니다. Linux 바이너리에서 setuid 루트를 실행하여 루트 사용 권한을 가지도록 하거나 단순히 루트로 RV를 실행하는 것이 그 두 가지 방식입니다. 이상적으로 보자면, 여러분은 setcap을 사용하여 파일 시스템에서 rv.bin 바이너리가 CAP_SYS_NICE만 소유하도록 마킹함으로써 비-루트 사용자가 이를 실시간으로 실행할 수 있도록 할 수 있지만 저희는 이를 가능하게 하지 못했습니다(이를 아직 완벽히 이해하지 못한 탓일 수도 있음).

Mac에서 RV 3.10.8은 기본적으로 실시간 앱이며, 어떤 특별한 사용 권한이 필요하지 않습니다.

Windows에서 RV 3.10.8은 자체 우선 순위를 관리자(Admin) 사용 권한 없이 가능한 최대 우선 순위까지 높입니다.

참고: RV는 더 높은 우선 순위로 실행될 때에는 디스플레이 스레드와 오디오 스레드, 두 스레드만 참조합니다. 이 스레드 중 어느 하나도 많은 컴퓨팅 작업을 수행하지는 않습니다. 보통 둘 모두 차단되어 있습니다. 따라서 RV가 너무 많은 커널 리소스를 소모할까 걱정할 필요는 없습니다.

재생률 및 V-Sync

궁극적으로 매끄럽게 재생되도록 하는 데 가장 큰 장애물은 재생 FPS의 효과를 모니터 재생률과 함께 인식하는 것입니다. 예를 들어, LCD 모니터가 기본적으로 ~60Hz의 재생률(초당 60회 재생)을 가지는 경우가 대표적입니다. 60Hz 모니터에서 24 FPS 자료를 재생하면 3/2 풀다운과 비슷한 현상이 발생합니다. 가장 매끄러운 재생을 위한 이상적인 재생률은 48 또는 72Hz 등 24의 배수인 재생률입니다. 또한, "60Hz" 모니터가 실제로는 59.88Hz일 수 있기 때문에 30 FPS 자료도 완벽히 매끄럽게 재생되지 않을 수 있다는 점도 염두에 두십시오. 최적의 결과를 얻기 위해서는 59.88 / 2 (29.94) FPS가 필요합니다.

멀티 모니터 시스템

연결된 모니터가 여러 대인 시스템은 다른 문제가 있습니다. RV가 자료를 재생 중인 모니터가 동기화 중인 모니터가 아닐 수 있다는 것입니다. 이 경우 재생이 매우 불규칙할 수 있습니다. 예를 들어 Linux에서는 드라이버가 모니터 한 대에만 동기화될 수 있으며, RV가 시작된 후에는 동기화 모니터를 변경할 수 없습니다. Linux에서는 환경 변수 __GL_SYNC_DISPLAY_DEVICE를 설정하여 드라이버가 동기화에 사용하는 모니터를 변경할 수 있습니다. 다음은 Nvidia의 드라이버 README에서 가져온 관련 문구입니다.

TwinView와 함께 __GL_SYNC_TO_VBLANK를 사용할 때 OpenGL은 디스플레이 장치 중 하나와만 동기화할 수 있습니다. 이로 인해 OpenGL이 동기화하지 않는 디스플레이 장치에서 테어링 손상이 발생할 수 있습니다. __GL_SYNC_DISPLAY_DEVICE 환경 변수를 사용하여 OpenGL이 동기화해야 하는 디스플레이 장치를 지정할 수 있습니다. 이 환경 변수를 "CRT-1" 같은 디스플레이 장치의 이름으로 설정해야 합니다. 존재하는 디스플레이 장치 목록과 해당 이름의 목록을 X 로그 파일의 "Connected displaydevice(s):" 행에서 찾으십시오. 10장, TwinView 구성 "Twinview 구성" 및 16장, 프로그래밍 모드에서 동일한 모드 타이밍 보장(Ensuring Identical Mode Timing) 단원을 참조하면 유용할 수 있습니다.

RV의 V-Sync와 드라이버 V-Sync 비교

끝으로, RV를 드라이버의 GL V-Sync와 RV의 V-Sync 모두를 설정한 상태에서 실행하지 마십시오. 실행하는 경우 거의 확실히 재생 불량 문제가 발생합니다. 둘 중 어느 하나만 사용하십시오. 시스템에서 어느 것의 타이밍이 더 나은지 시험해 볼 수도 있습니다. 이 설정은 다음과 같이 찾을 수 있습니다.

  • 렌더링(Rendering) 탭의 RV 기본 설정(RV Preferences)에 "비디오 동기화(Video Sync)" 체크박스가 있습니다.
  • Nvidia 설정 GUI에 openGL 'VBlank에 동기화(Sync to VBlank)' 체크박스가 있습니다.
Nvidia에서는 가능하면 드라이버 V-Sync를 사용하고, RV의 V-Sync를 비활성화할 것을 권장합니다. Linux에서는 RV 3.12.12가 드라이버가 동기화에 사용 중인 모니터를 감지하여, 이 모니터가 RV가 재생 중인 모니터가 아니면 경고를 표시합니다(셸 또는 콘솔 창에 INFO 메시지 출력). 프리젠테이션 모드에서는 RV 3.12.12가 프리젠테이션 장치가 Linux의 동기화 장치가 아닌 경우 메시지 상자를 표시합니다.
 
팔로우